ICs for Communications Multichannel Network Interface Controller for HDLC MUNICH32 PEB 20320 Version 3.4 User's Manual 01.2000 DS3 * PEB 20320 Revision History: Current Version: 01.2000 Previous Version: User's Manual 1998-06-01 DS2 (V3.4) Page (in previous Version) Page (in current Version) Subjects (major changes since last revision) Package P-TQFP-176-1 removed from User's Manual. For questions on technology, delivery and prices please contact the Infineon Technologies Offices in Germany or the Infineon Technologies Companies and Representatives worldwide: see our webpage at http://www.infineon.com * ABM(R), AOP(R), ARCOFI(R), ARCOFI(R)-BA, ARCOFI(R)-SP, DigiTape(R), EPIC(R)-1, EPIC(R)-S, ELIC(R), FALC(R)54, FALC(R)56, FALC(R)-E1, FALC(R)-LH, IDEC(R), IOM(R), IOM(R)-1, IOM(R)-2, IPAT(R)-2, ISAC(R)-P, ISAC(R)-S, ISAC(R)-S TE, ISAC(R)-P TE, ITAC(R), IWE(R), MUSAC(R)-A, OCTAT(R)-P, QUAT(R)-S, SICAT(R), SICOFI(R), SICOFI(R)-2, SICOFI(R)-4, SICOFI(R)-4C, SLICOFI(R) are registered trademarks of Infineon Technologies AG. ACETM, ASMTM, ASPTM, POTSWIRETM, QuadFALCTM, SCOUTTM are trademarks of Infineon Technologies AG. Edition 01.2000 Published by Infineon Technologies AG, SC, Balanstrae 73, 81541 Munchen (c) Infineon Technologies AG 2000. All Rights Reserved. Attention please! As far as patents or other rights of third parties are concerned, liability is only assumed for components, not for applications, processes and circuits implemented within components or assemblies. The information describes the type of component and shall not be considered as assured characteristics. Terms of delivery and rights to change design reserved. Due to technical requirements components may contain dangerous substances. For information on the types in question please contact your nearest Infineon Technologies Office. Infineon Technologies AG is an approved CECC manufacturer. Packing Please use the recycling operators known to you. We can also help you - get in touch with your nearest sales office. By agreement we will take packing material back, if it is sorted. You must bear the costs of transport. For packing material that is returned to us unsorted or which we are not obliged to accept, we shall have to invoice you for any costs incurred. Components used in life-support devices or systems must be expressly authorized for such purpose! Critical components1 of the Infineon Technologies AG, may only be used in life-support devices or systems2 with the express written approval of the Infineon Technologies AG. 1 A critical component is a component used in a life-support device or system whose failure can reasonably be expected to cause the failure of that life-support device or system, or to affect its safety or effectiveness of that device or system. 2 Life support devices or systems are intended (a) to be implanted in the human body, or (b) to support and/or maintain and sustain human life. If they fail, it is reasonable to assume that the health of the user may be endangered. PEB 20320 Preface The Multichannel Network Interface Controller for HDLC (MUNICH32) is a Multichannel Protocol Controller for a wide area of telecommunication and data communication applications. Organization of this Document This User's Manual is divided into 9 chapters. It is organized as follows: * Chapter 1, Introduction Gives a general description of the product and its family, lists the key features, and presents some typical applications. * Chapter 2, Functional Description This chapter provides a detailed description of the interfaces and the protocol modes. * Chapter 3, Operational Description Provides a description of MUNICH32 reset procedure and initialization. * Chapter 4, Detailed Register Description Gives a detailed description of the shared memory organization. * Chapter 5, Application Notes * Chapter 6, Application Hints * Chapter 7, Electrical Characteristics Gives a detailed description of all electrical DC and AC characteristics and provides timing diagrams and values for all interfaces. * Chapter 8, Package Outlines * Chapter 9, Appendix This chapter provides source code examples. Your Comments We welcome your comments on this document as we are continuously aiming at improving our documentation. Please send your remarks and suggestions by e-mail to sc.docu_comments@infineon.com Please provide in the subject of your e-mail: device name (MUNICH32), device number (PEB 20320), device version (Version 3.4), and in the body of your e-mail: document type (User's Manual), issue date (01.2000) and document revision number (DS3). User's Manual 3 01.2000 PEB 20320 User's Manual 4 01.2000 PEB 20320 Table of Contents Page 1 1.1 1.2 1.3 1.4 1.5 1.6 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Pin Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Pin Definitions and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Logic Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Functional Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 System Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 2 2.1 2.2 2.2.1 2.2.2 2.2.3 2.3 2.4 2.5 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Serial Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Microprocessor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Intel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Motorola Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 DMA Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Basic Functional Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Detailed Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76 Boundary Scan Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 3 3.1 3.2 Operational Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 Reset State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 Initialization Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132 4 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.3 4.4 Detailed Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 Organization of the Shared Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 Control and Configuration Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 Action Specification (Read Once After Each Action Request Pulse) . . .136 Interrupt Queue Specification . . . . . . . . . . . . . . . . . . . . . . .140 Interrupt Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Time Slot Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Channel Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149 Current Receive and Transmit Descriptor Address . . . . . . . . . . . . . .161 Transmit Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162 Receive Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 5 5.1 5.1.1 5.1.1.1 5.1.1.2 5.1.1.3 5.1.1.4 5.1.2 5.1.3 5.1.3.1 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Test Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Test Loop Definitions for the MUNICH32 . . . . . . . . . . . . . . . . . . . . . . .173 Internal Complete Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Internal Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .174 External Complete Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174 External Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Test Loop Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176 Test Loop Deactivation and Switching . . . . . . . . . . . . . . . . . . . . . . . . . .176 Software Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 User's Manual 5 01.2000 PEB 20320 Table of Contents Page 5.1.3.2 5.1.4 5.1.4.1 5.1.4.2 5.2 5.2.1 5.2.2 5.2.3 5.2.3.1 5.2.3.2 5.2.4 5.2.5 5.2.6 5.2.7 5.3 5.3.1 5.3.2 Hardware Reset Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Test Loop Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 Internal Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 External Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .180 MUNICH32 in a LAN/WAN Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188 Device Driver Module MUNICH32 . . . . . . . . . . . . . . . . . . . . . . . . . . .191 Application Module MROUTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194 Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197 Final Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 Adaption of the 68040 P Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205 Memory Bus Occupancy for a Single MUNICH32 . . . . . . . . . . . . . . . . . . .214 Bus Occupancy Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 Bus Occupancy for Idle Tx Channels . . . . . . . . . . . . . . . . . . . . . . . . . .218 6 6.1 6.2 6.3 6.3.1 6.3.2 Application Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220 Frequency Adaption in an Intel 368 Common Bus System . . . . . . . . . . . .220 MUNICH32 Memory Space Requirement . . . . . . . . . . . . . . . . . . . . . . . . .223 Serial Interface to different PCM Systems . . . . . . . . . . . . . . . . . . . . . . . . .224 MUNICH32 for SIEMENS Primary Access Interface . . . . . . . . . . . . . . .224 MUNICH32 in Systems with MITEL ST BUS . . . . . . . . . . . . . . . . . . . . .227 7 7.1 7.2 7.3 7.4 7.5 7.6 Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 Absolute Maximum Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 Capacitances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231 AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231 Microprocessor Interface Intel Bus Mode . . . . . . . . . . . . . . . . . . . . . . . . .232 Microprocessor Interface Motorola Bus Mode . . . . . . . . . . . . . . . . . . . . . .235 8 Package Outlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242 9 9.1 9.2 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Source Code Extract MUNICH32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245 User's Manual 6 01.2000 PEB 20320 Introduction 1 Introduction The Multichannel Network Interface Controller for HDLC (MUNICH32) is a Multichannel Protocol Controller, which handles up to 32 data channels of a full duplex PCM highway. It performs layer 2 HDLC formatting/deformatting or V.110 and X.30 protocols up to a network data rate of 38.4 Kbit/s as well as transparent transmission for the DMI mode 0, 1 and 2. The processed data is passed on to an external memory shared with one or more host processors. MUNICH32 is compatible with the LAPD ISDN (Integrated Services Digital Network) protocol specified by CCITT as well as with HDLC, SDLC, LAPB DMI protocols. It provides any rate adaption for time slot transmission data rate from 64 Kbit/s down to 8 Kbit/s and the concatenation of any time slots to data channels, supporting the ISDN H0, H11, H12 superchannels. Due to these functions the MUNICH32 can be used in a wide area of telecommunication and data communication applications, e.g. in central office switches, for the connection of a digital PABX to a host computer, as a central D-channel controller to 32 ISDN basic access D-channels or as a multiplexer for terminals and other peripherals. Up to 4 MUNICH32s can be connected to one PCM highway, so a D-channel controller with 128 channels can be achieved. User's Manual 7 01.2000 Multichannel Network Interface Controller for HDLC MUNICH32 Version 3.4 1.1 PEB 20320 CMOS Features * Serial Interface - Up to 32 independent communication channels. - Serial multiplexed (full duplex) input/output for 2048-, 4096-, 1544- or 1536-Kbit/s PCM highways. * Dynamic Programmable Channel Allocation - Compatible with T1/DS1 24-channel and CEPT 32-channel PCM byte format. P-MQFP-160-1 - Concatenation of any, not necessarily consecutive, time slots to superchannels independently for receive and transmit direction. - Support of H0, H11, H12 ISDN-channels. - Subchanneling on each time slot possible. * Bit Processor Functions (adjustable for each channel) - HDLC Protocol - Automatic flag detection and transmission - Shared opening and closing flag - Detection of interframe-time-fill change, generation of interframe-time-fill `1's or flags - Zero bit insertion - Flag stuffing and flag adjustment for rate adaption - CRC generation and checking (16 or 32 bits) - Transparent CRC option per channel and/or per message - Error detection (abort, long frame, CRC error, 2 categories of short frames, non-octet frame content) - Special short frame mode to allow reception of `frames' with a least on byte length - ABORT/IDLE generation Type Package PEB 20320 P-MQFP-160-1 User's Manual 8 01.2000 PEB 20320 Introduction - V.110/X.30 Protocol - Automatic synchronization in receive direction, automatic generation of the synchronization pattern in transmit direction - E / S / X bits freely programmable in transmit direction, van be changed during transmission; changes monitored and reported in receive direction - Generation/detection of loss of synchronism - Bit framing with network data rates from 600 bit/s up to 38.4 Kbit/s - Transparent Mode A - Slot synchronous transparent transmission/reception without frame structure - Bit-overwrite with fill/mask bits - Flag generation, flag stuffing, flag extraction, flag generation in the abort case with programmable flag - Transparent Mode B - Transparent transmission/reception in frames delimited by 00H flags - Shared opening and closing flag - Flag stuffing, flag detection, flag generation in the abort case - Error detection (non octet frame content, short frame, long frame) - Transparent Mode R - Transparent transmission/reception with GSM 08.60 frame structure - Automatic 0000H flag generation/detection - Support of 40, 391/2, 401/2 octet frames - Error detection (non octet frame content, short frame, long frame) - Protocol Independent - Channel inversion (data, flags, IDLE code) - Format conventions as in CCITT Q.921 2.8 - Data over- and underflow detected * Processor Interface - ON-CHIP 64-channel DMA controller with buffer chaining capability. - Compatible with Motorola 68020 processor family and Intel 32-bit processor (80386). - 32 bit data bus and 32 bit address bus (4 Gbyte RAM addressable, Motorola and Intel non-parity) or 28 bit address bus (256 Mbyte RAM addressable, Intel parity) - Intel parity mode with data byte parity (4 parity bits) - Parity check for read accesses - Parity generation for write accesses - Interrupt-circular buffer with variable size - Maskable interrupts for each channel - P interface buffer of depth 16 long words for adaptive bus occupation User's Manual 9 01.2000 PEB 20320 Introduction * General - Connection of up to four MUNICH32 supporting a 128-channel basic access D-channel controller. - ON-CHIP receive and transmit data buffer; the buffer size is 256 bytes each. - HDLC protocol or transparent mode, support of ECMA 102, CCITT I4.63 RA2, V.110, X.30, DMI mode 0, 1, 2 (bit rate adaption), GSM 08.60 TRAU frames. - LOOP mode, complete loop as well as single channel loop - JTAG boundary scan test - Advanced low-power CMOS technology - TTL-compatible inputs/outputs - 160 pin P-MQFP package User's Manual 10 01.2000 PEB 20320 Introduction 1.2 Pin Configuration (top view) A7 D7 V DD V SS A6 D6 A5 D5 V DD V SS V SS A4 D4 A3 D3 V DD V SS V SS A2 D2 BE0 D1 V DD V SS BE1 D0 BE2 VDD V SS BE3 W,R/R;W V DD V SS V SS DS/PCHK ADS/AS V DD V SS HOLD/BR BGACK/PM P-MQFP-160-1 120 121 110 100 90 81 80 130 70 MUNICH32 PEB 20320 140 60 150 50 Index Marking 160 1 10 20 30 41 40 D20 A20 V SS V DD D21 A21 D22 A22 V SS V SS V DD D23 A23 D24 A24 V SS V DD D25 A25 D26 A26 V SS V SS V DD D27 A27 D28 A28/DP0 V SS V SS V DD D29 A29/DP1 D30 A30/DP2 V SS V DD D31 A31/DP3 INT/INT D8 A8 VSS V DD D9 A9 D10 A10 VDD VSS VDD D11 A11 D12 A12 VSS VDD D13 A13 VDD VSS D14 A14 VSS VDD D15 A15 D16 A16 VSS VSS VDD D17 A17 D18 A18 VSS VDD D19 A19 HLDAO/BGO HLDA/BG V DD V SS BERR READY/DSACK B16 I/M N.C. N.C. N.C. TCLK TSP TDATA AR TEST V SS V DD V SS SCLK RESET V SS V DD V DD JTEST3 JTEST2 JTEST1 JTEST0 N.C. CI4 CI3 CI2 CI1 CI0 RDATA RSP RCLK N.C. N.C. N.C. ITP03487 Figure 1 User's Manual 11 01.2000 PEB 20320 Introduction 1.3 Pin Definitions and Functions Pin Definitions and Functions Pin No. P-MQFP-160-1 Symbol 83, 87, 88, 92, 97, 103, 104, 110, 111, 117, 123, 130, 136, 141, 144, 150, 151, 157, 3, 9, 10, 16, 22, 23, 29, 30, 36, 59, 62, 64, 77 VSS I Ground (0 V) All pins must have the same level. 73 I/M I Intel Bus Mode or Motorola Bus Mode By connecting this pin to either VSS or VDD the bus interface can be adapted to either Intel or Motorola environment. The data is interpreted either in Intel or Motorola manner; i.e. little or big endian convention. I/M = low: Intel bus mode I/M = high: Motorola bus mode 39 A31 O DP3 I/O Address Bit 31 (Intel non-parity/Motorola) tristate when unused. Data Parity 3 (Intel parity mode), bidirectional tristate line containing/ expecting parity bit of D(31:24). A30 O DP2 I/O 35 Input (I) Function Output (O) Address Bit 30 (Intel non-parity/Motorola) tristate when unused. Data Parity 2 (Intel parity mode), bidirectional tristate line containing/ expecting parity bit of D(23:16). Note: Input pins that are unused in a specific configuration must be strapped to VSS. I/O or output pins that are unused in a specific configuration must be left open! User's Manual 12 01.2000 PEB 20320 Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 Symbol 33 A29 O Address Bit 29 (Intel non-parity/Motorola) tristate when unused. DP1 I/O Data Parity 1 (Intel parity mode), bidirectional tristate line containing/ expecting parity bit of D(15:8) A28 O Address Bit 28 (Intel non-parity/Motorola) tristate when unused DP0 I/O Data Parity 0 (Intel parity mode), bidirectional tristate line containing/ expecting parity bit of D(7:0) 26, 21, 19, 15, A(27:2) 13, 8, 6, 2, 160, 156, 154, 149, 147, 143, 139, 135, 133, 128, 126, 122, 120, 116, 114, 109, 107, 102 O Address Bus tristate when unused. 91, 94, 96, 100 O Byte Enable (Intel bus mode) The MUNICH32 provides word and long word transfer. The byte enables determine the address offset to the address A31 ... A2, the actual word has been stored to. Address Offset Size (Motorola mode) Indicates the number of bytes remaining to be transferred for this access. These signals define the active sections of the data bus. In both cases these signals are tristate when unused. See Chapter 2.2 for details. 28 User's Manual BE(3:0) Input (I) Function Output (O) 13 01.2000 PEB 20320 Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 Symbol Input (I) Function Output (O) 38, 34, 32, 27, D(31:0) 25, 20, 18, 14, 12, 7, 5, 1, 159, 153, 148, 146, 142, 138, 134, 132, 127, 125, 121, 119, 115, 113, 108, 106, 101, 99, 95 I/O Data Bus The data bus lines are bidirectional tristate lines which interface with the system's data bus. 86 DS O Data Strobe (Motorola mode) This signal indicates that valid data is to be placed on the data bus (read cycle) or has been placed on the data bus by the MUNICH32 (write cycle). PCHK O Parity Check (Intel parity mode) This signal indicates, whether the parity bits of a read cycle are valid (PCHK high) or invalid (PCHK low). See Chapter 2.2.1 for details. 84, 93, 89, 98, 105, 112, 118, 124, 129, 131, 137, 140, 145, 152, 158, 4, 11, 17, 24, 31, 37, 57, 58, 63, 78 VDD I Supply voltage 5 V 5% All pins must have the same level. 85 ADS O Address Status (Intel bus mode) This signal indicates that a valid bus cycle definition and address are being driven at the pins. AS O Address Strobe (Motorola bus mode) A valid address is transmitted on the address bus at the falling edge of AS. In both cases this signal is active low and tristate when unused. User's Manual 14 01.2000 PEB 20320 Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 Symbol Input (I) Function Output (O) 90 W/R O Write/Read (Intel bus mode) This signal distinguishes write from read operations. R/W O Read/Write (Motorola bus mode) This signal distinguishes between read and write operations. In both cases this signal is tristate when unused. 75 User's Manual READY I Ready (Intel bus mode) This signal indicates that the current bus cycle is complete. When READY is asserted during a read cycle the MUNICH32 latches the input data and terminates the cycle. When READY is asserted during a write cycle the MUNICH32 terminates the cycle. DSACK I Data Transfer Acknowledge (Motorola bus mode) This active low input indicates that a data transfer may be performed. During a read cycle data becomes valid at the falling edge of DSACK. The data is latched internally and the bus cycle is terminated. During a write cycle the falling edge of DSACK marks the latching of data and the bus cycle is terminated. 15 01.2000 PEB 20320 Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 Symbol 76 BERR I Bus Error (Intel and Motorola bus mode) This active low signal informs the MUNICH32 that a bus cycle error has occurred. The MUNICH32 terminates the bus cycle. In case of an erroneous read cycle in the control and configuration section an `Action Request Fail' interrupt is generated and the action is suspended. In case of an erroneous read cycle in the transmit data section the corresponding frame is aborted and a FO interrupt is generated. In all other cases of read or write cycles terminated with an error condition no further actions are performed by the MUNICH32. Please see Chapter 2.2, `Microprocessor Interface', first paragraph and Figure 18. As bus cycles are executed without time limit this signal prevents a hang-up situation of the MUNICH32. 74 B16 I Word Operation Setting this bit to VDD causes the MUNICH32 to perform 32-bit long word accesses to the shared memory, setting it to VSS causes the MUNICH32 to perform 16-bit word accesses on the data lines D(15:0) only. In 16-bit word access mode the data lines D(31:16) should be left open. This bit is not dynamic and should be set to VDD in Intel parity mode. User's Manual Input (I) Function Output (O) 16 01.2000 PEB 20320 Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 Symbol 82 HOLD O Bus Hold Request (Intel bus mode) This signal is driven high when the MUNICH32 requests the control of the bus. BR I/O Bus Request (Motorola bus mode) This signal is driven low when the MUNICH32 requests the control of the bus and is interpreted when another MUNICH32 wants to be the bus master. HLDA I Bus Hold Acknowledge (Intel bus mode) This active high signal indicates that the processor has released the control of the bus. The MUNICH32 starts the bus cycles. BG I Bus Grant (Motorola bus mode) This active low signal indicates that the MUNICH32 may assume the bus mastership. 79 81 BGACK PM User's Manual Input (I) Function Output (O) I/O Bus Grant Acknowledge (Motorola bus mode) This signal is driven low by the device, when it has become the bus master. It also informs the MUNICH32 whether another device is bus master. I Parity Mode (Intel bus mode) This signal has to be strapped to VDD before reset to enable the Intel parity mode or to VSS before reset to enable the Intel non-parity mode. It has to be left strapped during reset and operation. 17 01.2000 PEB 20320 Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 Symbol 80 HLDAO O Bus Hold Acknowledge Passing ON (Intel bus mode) If another MUNICH32 has initiated a HOLD REQUEST the HOLD ACKNOWLEDGE is passed on via HLDAO. The MUNICH32 does not give another HOLD REQUEST before the HOLD ACKNOWLEDGE has been deactivated in order to prevent blocking in the case of continuous request by one MUNICH32. BGO O Bus Grant Acknowledge (Motorola bus mode) If the MUNICH32 has not requested the bus mastership it passes on the BUS GRANT. The MUNICH32 does not give another BUS REQUEST before the BUS REQUEST and the BUS GRANT ACKNOWLEDGE have been deactivated in order to prevent blocking in the case of continuous request by one MUNICH32. AR I Action Request AR must be pulsed low to cause an action of the MUNICH32. The AR is activated for updating the mode and channel configurations, setting a test loop, or initializing the interrupt queue. The min. time between Reset and first AR is 500 s. 66 User's Manual Input (I) Function Output (O) 18 01.2000 PEB 20320 Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 Symbol 40 INT/INT O Interrupt Request An interrupt is given when a transmission/ reception error is detected, frames are received or transmitted, or a host initiated action is performed. The interrupt pulse signal interacts with a write cycle to the shared memory. The data written into the interrupt queue contains the interrupt specification. The interrupt is active high for Intel bus mode and active low for Motorola bus mode. 44 RCLK I Receive Clock This clock provides the data clock for RDA T1/DS1 24-channel 1.544 MHz 24-channel 1.536 MHz CEPT 32-channel 2.048 MHz 32-channel 4.096 MHz 45 RSP I Receive Synchronization Pulse This signal provides the reference for the receive PCM frame synchronization. It marks the first bit in the PCM frame. 46 RDATA I Receive Data Serial data is received at this PCM input port. The MUNICH32 supports the T1/ DS1 24-channel PCM format, the CEPT 32-channel PCM format as well as a 32channel PCM format with 4.096-Mbit/s bit rate. 61 SCLK I System Clock PCM highway system clock highway frequency 32-channel 16.384 MHz 2.048 or 4.096 MHz 24-channel 12.288 MHz 1.536 MHz 24-channel 12.352 MHz 1.544 MHz User's Manual Input (I) Function Output (O) 19 01.2000 PEB 20320 Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 Symbol 51 ... 47 CI(4:0) I 56 ... 53 JTEST (3:0) I/O 65 TEST I Test If this bit is set to VDD MUNICH32 works in a test mode. For the functional working mode this bit must be set to VSS. 67 TDATA O Transmit Data Serial data is sent by this PCM output port is push-pull for active bits in the PCM frame and tristate for inactive bits. 68 TSP I Transmit Synchronization Pulse This signal provides the reference for the transmit frame synchronization. It marks the last bit in the PCM frame. 69 TCLK I Transmit Clock This clock provides the data clock for TDATA T1/DS1 24-channel 1.544 MHz 24-channel 1.536 MHz CEPT 32-channel 2.048 MHz 32-channel 4.096 MHz User's Manual Input (I) Function Output (O) Chip Identification Up to four MUNICH32 can be connected to the PCM highway. These inputs define the start address of the control section pointer in the shared memory. CI4 is the polarity of A31 ... A22 CI3 is the polarity of A21 ... A16 CI2 is the polarity of A15 ... A4 CI1 is the polarity of A3 CI0 is the polarity of A2 A1, A0 are always `00' Test Pins The MUNICH32 supports the JTAG boundary scan test and the JTAG test standards. 20 01.2000 PEB 20320 Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 Symbol 60 RESET I Reset 41, 42, 43, 52, 70, 71, 72 N.C. - No Connect These pins are reserved and should not be connected User's Manual Input (I) Function Output (O) 21 01.2000 PEB 20320 Introduction 1.4 Logic Symbol VSS BE (3:0) RCLK 30 1) RSP 32 RDATA D (31:0) TCLK TSP W/R R/W TDATA ADS/AS Microprocessor Bus Interface DS/PCHK READY/DSACK Serial Interface MUNICH32 PEB 20320 I/M BERR 5 B16 CI (4:0) HOLD/BR 4 HLDA/BG TEST JTEST (3:0) BGACK/PM System Interface RESET HLDAO/BGO SCLK AR VDD INT/INT ITL03488 1) A31/DP3, A30/DP2, A29/DP1, A28/DP0, A[27:2] Figure 2 MUNICH32 Logic Symbol User's Manual 22 01.2000 PEB 20320 Introduction 1.5 Functional Block Diagram TCLK TSP TDATA TEST RESET SCLK JTEST CI (4:0) 4 5 RCLK RSP RDATA Serial Interface/Formatter Controller Unit CD TF Transmit Formatter CSR Configuration and State RAM RD Receive Deformatter TB Transmit Buffer CM DMA Controller RB Receive Buffer MI Microprocessor Bus Interface 32 BE (3:0) A (31:2) D (31:0) ADS/ DS W/R READY/ HOLD/ HLDA/ BGACK HLDAO/ R/W DSACK BR AS BGO BG PM BERR INT/ AR B16 I/M ITB03495 INT Figure 3 Block Diagram of MUNICH32 User's Manual 23 01.2000 PEB 20320 Introduction The internal functions of MUNICH32 are partitioned into 8 major blocks. 1. Serial Interface, Formatter Control Unit CD - Parallel-Serial conversion, PCM timing, switching of the test loops, controlling of the multiplex procedure. 2. Transmit Formatter TF - HDLC frame, bit stuffing, flag generation, flag stuffing and adjustment, CRC generation, transparent mode transmission and V.110, X.30 80 bit framing. 3. Transmit Buffer TB - Buffer size of 64 long words allocated to the channels, i.e. eight PCM frames can be stored before transmission, individual channel capacity programmable. 4. Receive Deformatter RD - HDLC frame, zero-bit deletion, flag detection, CRC checking, transparent mode reception and V.110, X.30 80 bit framing. 5. Receive Buffer RB - Buffer size of 64 long words allocated to the channels, i.e. eight PCM frames can be stored, individual long words are freely accessible by each channel. 6. Configuration and State RAM CSR - Since the Transmit Formatter, Receive Deformatter are used in a multiplex manner, the state and configuration information of each channel has to be stored. 7. DMA Controller CM - Interrupt processing, memory address calculation, chaining list handling, chip configuration. 8. P interface MI - Motorola/Intel microprocessor interface. User's Manual 24 01.2000 PEB 20320 Introduction 1.6 System Integration The MUNICH32 is designed to handle up to 32 data channels of a PCM highway. It transfers the data between the PCM highway and a memory shared with a host processor via a 32-bit P interface. At the same time it performs protocol formatting and deformatting as well as rate adaption for each channel independently. The host sets the operating mode, bit rate adaption method and time slot allocation of each channel by writing the information into the shared memory. Using subchanneling each time slot can be shared between up to four MUNICH32s; so that in one single time slot four different D-channels can be handled by four MUNICH32s. Figure 4, Figure 5 and Figure 6 give a general overview of system integration of the MUNICH32. PCM Highway (2.048 Mbit/s, 1.544 Mbit/s, 1.536 Mbit/s, 4.096 Mbit/s) HLDA HLDA HOLD HLDA HLDA CPU HLDA 3 MUNICH32 HOLD HLDAO HLDA 2 MUNICH32 HOLD HLDAO HLDA 1 MUNICH32 HOLD HLDAO HLDA 0 MUNICH32 HOLD Up to 4 MUNICH32 HLDA System Bus Memory Optional CPU ITS03489 Figure 4 General System Integration (Intel Bus Mode) User's Manual 25 01.2000 PEB 20320 Introduction PCM Highway (2.048 Mbit/s, 1.544 Mbit/s, 1.536 Mbit/s, 4.096 Mbit/s) HOLD HLDAO HLDA MUNICH32 HLDA HOLD MUNICH32 System Bus Memory CPU ITS03490 Figure 5 General System Interface (Intel Bus Mode) PCM Highway MUNICH32 CPU BR BG BGACK MUNICH32 BR BG BGACK Up to 4 MUNICH32 System Bus Memory Optional CPU ITS03491 Figure 6 General System Interface (Motorola Bus Mode) User's Manual 26 01.2000 PEB 20320 Introduction MUNICH32's bus interface consists of a 32 bit bidirectional data bus (D31 ... D0), 32/28 Address lines (A31 ... A2, BE3 ... BE0) or (A27 ... A2, BE3 ... BE0), four data byte parity lines DP(3:0), five lines (W/R/R/W, ADS/AS, DS/PCHK, BERR READY/DSACK) to control and monitor the bus cycle, one action request and one Interrupt line. The system bus allocation is controlled by the four signals (HOLD/BR, HLDA/BG, BGACK, HLDAO/BGO). A mode pin allows the bus interface to be configured for either Intel or Motorola mode. An operation mode pin B16 enables the transfer of a 32 bit long word in two consecutive 16 bit word operations. Figure 7, Figure 8, Figure 9, Figure 10 and Figure 11 illustrate how the MUNICH32 may be used in different applications, like in a Primary Rate Interface, a Router, a Packet Switch and a Central D-Channel Handler, as part of an ISDN switching system. T1/S2 Line Line Interface FALC54 PEB 2254 Interrupt Controller System Memory PCM System Interface System Bus INT/INT System Bus Controller AR Host Interface (Alternative B) Local CPU Bus MUNICH32 PEB 20320 CPU Host Interface (Alternative A) CPU Bus Arbitration ITS07372 Figure 7 Architecture of a Primary Access Board User's Manual 27 01.2000 PEB 20320 Introduction PCM Highway Signaling Highway R Interrupt Controller EPIC PEB 2056 HSCX SAB 82525 System Memory System Bus INT/INT AR Host Interface (Alternative B) System Bus Controller Local CPU Bus MUNICH32 PEB 20320 Host Interface (Alternative A) CPU PCM System Interface CPU Bus Arbitration ITS04829 Figure 8 Architecture of a Central D-Channel Handler User's Manual 28 01.2000 PEB 20320 Introduction V.24, V.21, V.35, ... T1/S2 Line Line Interface Line Driver FALC54 PEB 2254 ESCC8 SAB 82538 Interrupt Controller System Memory System Bus INT/INT AR System Bus Controller Local CPU Bus PCM System Interface MUNICH32 PEB 20320 CPU CPU Bus Arbitration ITS07374 Figure 9 Architecture of a Packet Switch/Router User's Manual 29 01.2000 PEB 20320 Introduction T1/S2 Line Line Interface FALC54 PEB 2254 Interrupt Controller PCM System Interface System Memory System Bus INT/INT System Bus Controller AR Local CPU Bus Local CPU Bus CPU MUNICH32 PEB 20320 (not compatible with Intel 386 or Motorola 68020) CPU Bus Arbitration CPU Bus Arbitration ITS07371 Figure 10 MUNICH32 in a System with a RISC CPU Note: To reduce complexity the host interface is not explicitly shown here. User's Manual 30 01.2000 PEB 20320 Introduction T1/S2 Line Line Interface FALC54 PEB 2254 Interrupt Controller PCM System Interface System Memory System Bus INT/INT System Bus Controller AR Local CPU Bus Local CPU Bus Multi Port RAM Controller MUNICH32 PEB 20320 Multi Port Memory CPU Bus Arbitration CPU CPU Bus Arbitration ITS07373 Figure 11 MUNICH32 in a System using Multiport Memory Note: To reduce complexity the host interface is not explicitly shown here. User's Manual 31 01.2000 PEB 20320 Functional Description 2 Functional Description 2.1 Serial Interface The serial interface of MUNICH32 includes a data receive (RDATA) and a data transmit line (TDATA) as well as the accompanying control signals (RCLK = Receive Clock, RSP = Receive Synchronization Pulse, TCLK = Transmit Clock, TSP = Transmit Synchronization Pulse). The timings of the receive and transmit PCM highway are independent of each other, i.e. the frame positions and clock phases are not correlated. Data is transmitted and received either at a rate of 2.048 Mbit/s for the CEPT 32-Channel European PCM format (Figure 14) or 1.544 Mbit/s or 1.536 Mbit/s for the T1/DS1 24-Channel American PCM format (Figure 12 and Figure 13). MUNICH32 may also be connected to a 4.096-Mbit/s PCM system (Figure 15), where it handles either the even- or odd-numbered time slots, so all 64 time slots can be covered by connecting two MUNICH32s to the PCM highway. The actual bit rate of a time slot can be varied from 64 Kbit/s down to 8 Kbit/s for the receive and transmit direction. A fill mask code specified in the time slot assignment determines the bit rate and which bits of a time slot should be ignored. Any of these time slots can be combined to a data channel allowing transmission rates from 8 Kbit/s up to 2.048 Mbit/s. The frame alignment is established by the transmit and receive synchronization pulse (TSP, RSP), respectively. The sampled rising edge of TSP identifies the current bit on the serial line (TDATA) as the last bit of a PCM frame. The sampled rising edge of RSP indicates that the current bit on the serial line (RDATA) is the first bit of a PCM frame. The F-bit for the 1.544 MHz T1/DS1 24-channel PCM format is ignored in receive direction, the corresponding bit is tristate in transmit direction. It is therefore assumed that this channel is handled by a different device. For test purposes four different test loops can be switched. In a complete loop all logical channels are mirrored either from serial data output to input (internal loop) or vice versa (external loop). In a channelwise loop one single logical channel is logically mirrored either from serial data output to input (internal loop) or vice versa (external loop). A detailed description of the different loops is found in Chapter 4.2.1 and Chapter 5.1. User's Manual 32 01.2000 PEB 20320 Functional Description 125 s SLOT 0 SLOT 1 F 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 SLOT 23 PCM - Frame SLOT 23 SLOT 0 6 7 F 0 1 2 3 4 SLOT 1 5 6 7 TCLK TSP TDATA FILL/MASK Fill/Mask : Slot 0 T1/DS1 - Mode Transmit Frame Timing SLOT 23 10011000 SLOT 0 6 7 F 0 1 DATA DATA 2 3 4 SLOT 1 5 6 DATA DATA 7 RCLK RSP RDATA DATA DATA FILL/MASK Fill/Mask : Slot 0 T1/DS1 - Mode Receive Frame Timing 11010110 ITD03496 Figure 12 T1/DS1 Mode PCM Frame Timing 1.544 MHz Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC, TMB, TMR, V.110/X.30) or received as `1'-bit (TMA; one overwrite). Note 2: The fill/mask bit for the F-bit is not defined. TDATA is tristate for the F-bit, and the F-bit is ignored in the receive direction. Note 3: TSP and RSP must have one single rising and falling edge during a 125 s PCM frame. User's Manual 33 01.2000 PEB 20320 Functional Description 125 s SLOT 0 SLOT 1 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 SLOT 23 PCM - Frame SLOT 23 SLOT 0 6 7 0 1 2 3 4 SLOT 1 5 6 7 TCLK TSP TDATA FILL/MASK Fill/Mask : Slot 0 T1/DS1 - Mode Transmit Frame Timing SLOT 23 10011000 SLOT 0 6 7 0 1 DATA DATA 2 3 4 SLOT 1 5 6 DATA DATA 7 RCLK RSP RDATA DATA DATA FILL/MASK Fill/Mask : Slot 0 T1/DS1 - Mode Receive Frame Timing 11010110 ITD03497 Figure 13 T1/DS1 Mode PCM Frame Timing 1.536 MHz Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC, TMB, TMR, V.110/X.30) or received as `1'-bit (TMA; one overwrite). Note 2: TSP and RSP must have one single rising and falling edge during a 125 s PCM frame. User's Manual 34 01.2000 PEB 20320 Functional Description 125 s SLOT 0 SLOT 1 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 SLOT 31 PCM - Frame SLOT 31 SLOT 0 6 7 0 1 3 2 SLOT 1 5 4 6 7 TCLK TSP TDATA FILL/MASK Fill/Mask : Slot 0 CEPT - Mode Transmit Frame Timing SLOT 31 10011000 SLOT 0 6 7 0 1 DATA DATA DATA DATA 3 2 4 SLOT 1 5 6 DATA DATA 7 RCLK RSP RDATA DATA FILL/MASK Fill/Mask : Slot 0 CEPT - Mode PCM - Frame Timing 11010110 ITD03498 Figure 14 CEPT Mode PCM Frame Timing Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC, TMB, TMR, V.110/X.30) or received as `1'-bit (TMA; one overwrite). Note 2: TSP and RSP must have one single rising and falling edge during a 125 s PCM frame. User's Manual 35 01.2000 PEB 20320 Functional Description 125 s SLOT 0 SLOT 1 SLOT 31 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 TSP RSP 4.096 Mbit/s PCM-format: even numbered slot allocation 6 7 SLOT 0 SLOT 31 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 TSP RSP 4.096 Mbit/s PCM-format: odd numbered slot allocation ITD03528 Figure 15 4.096 Mbit/s PCM Frame Timing Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC, TMB, TMR, V.110/X.30) or received as `1'-bit (TMA; one overwrite). Note 2: TSP and RSP must have one single rising and falling edge during a 125 s PCM frame. User's Manual 36 01.2000 PEB 20320 Functional Description 125 s 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 x 64 kbit/s 1 0 2 1 3 4 1 5 6 7 8 7 9 1 ITD03499 Figure 16 Example: Programmable Channel Allocation for 32 Time Slots 125 s 0 1 2 0 3 4 5 1 2 6 7 3 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 x 64 kbit/s 4 3 5 1 2 6 ITD03500 Figure 17 Example: Programmable Channel Allocation for 24 Time Slots User's Manual 37 01.2000 PEB 20320 Functional Description 2.2 Microprocessor Interface A 64-channel DMA controller (32 channels in receive direction and 32 channels in transmit direction) with buffer chaining capability is integrated in the MUNICH32. It provides DMA functions for up to 32 full duplex channels and allows data transfer between the serial interface and an external memory. The MUNICH32 performs long word by long word transfers on a 32-bit bidirectional data bus (D(31:0)) and addresses up to 4 GByte of RAM with a 30-bit address bus (A(31:2)). The chip always works as a system bus master and can be operated in either a Intel or Motorola environment. MUNICH32 receives commands and data from the host processor via the shared memory. The host stores the action specification containing configuration initialization and monitor commands in the memory. Afterwards the host informs the MUNICH32 by generating an action request pulse (AR line). The MUNICH32 reacts by reading the action specification and informs the microprocessor by appending the respective interrupt information to the interrupt queue. In addition, the INT/INT line is activated during the write access belonging to the interrupt specification. The timing of the microprocessor interface is established according to the Intel 80386 or Motorola 68020 processor. The system clock (SCLK) provides the fundamental timing for the P interface and is the internal device clock. Each bus cycle performs a long word (B16 = 1) or a word (B16 = 0) transfer and takes four system clock periods in the fastest case, any number of wait clock cycles can be inserted. MUNICH32's architecture is based on a 32-bit data structure. Therefore MUNICH32 performs long word operations preferably. While the word operation mode is selected the long word operation is divided into two consecutive word operations. In the case of a read access the data of the two words are connected together to build a 32-bit long word before processing. Mode Operation Mode B16 BE(3-0) Access Intel 1 0 0 0H 3H CH long word MSB word LSB word Motorola 1 0 0 0H 8H AH long word MSB word LSB word For a read access first the MSB bytes of a long word will be transferred and then the LSB bytes via D(15:0). For a write access first the LSB-bytes of a long word will be transferred and then the MSB bytes via D(15:0). The signal B16 cannot be changed dynamically and should be set to `1' in Intel parity mode (parity mode is not available in 16-bit word Intel mode). User's Manual 38 01.2000 PEB 20320 Functional Description 2.2.1 Intel Mode The Intel mode has two submodes - parity mode (even parity) and non parity mode - to be chosen by strapping PM to `1' or `0' respectively. In Intel mode the lower (higher) ordered byte of a long word (D31 ... D0) is assigned to the lower (higher) ordered physical address. The read or write bus cycle is controlled by the signals W/R, ADS and READY as shown in Figure 18, Figure 19. Each bus cycle consists of two bus states (S1, S2). During state S1 the address signals and bus cycle definition signals are driven valid. Simultaneously, the address status ADS is asserted to indicate their availability. The bus cycles are terminated by asserting READY. READY is ignored on the first bus state S1 and sampled at the end of the following state S2. If READY is not asserted in S2 then wait cycles SW are inserted until a bus cycle end is detected. During a read cycle the MUNICH32 floats its data signals to allow external memory to drive the data bus. The input data and parity bits DP3-0 (if parity mode is selected) is latched when READY is asserted. During a write cycle MUNICH32 drives the data signals and parity bits DP3- 0 (if parity mode is selected) beginning in the second clock period of S1 until the first clock period following the cycle acknowledgment READY. If a bus cycle error indicated by BERR has occurred, the MUNICH32 terminates the bus cycle. In case of a read cycle in the control and configuration section an action request fail interrupt is generated and the action is suspended. In case of a read cycle in the transmit data section the corresponding frame is aborted and a FO interrupt is generated. In all other cases of read or write cycles terminated with an error condition no actions are performed. A 4-bit data byte parity bus DP3-0 is used in Intel mode if parity mode is selected by strapping PM to `1'. During a read access DP3-0 is supposed to contain the parity of D(31:24), D(23:16), D(15:8) and D(7:0) respectively. A low active output PCHK indicates whether the parity was correct (PCHK = 1) or wrong (PCHK = 0) in the clock cycle after the data/parity is latched. PCHK stays low 1 or 2 clock cycles. No further action is taken as consequence to a parity fail. As the memory access is performed by using one common system bus, bus management is done with the signals HOLD, HLDA and HLDAO as shown in Figure 20. The wired or HOLD line is driven high whenever one of the MUNICH32s has to perform a bus transfer. The activated HOLD ACKNOWLEDGE indicates that the bus control will be released. If the specific device has activated the HOLD itself, it will start the memory access. Otherwise it will pass the signal to the next cascaded device. Several memory accesses may be required if the MUNICH32 has not been granted access recently. In this example of four MUNICH32 devices sharing the same bus, each device will generate four memory cycles, giving a total of 16 cycles per HOLD/HLDA/HLDAO tenure. In order to prevent blocking in the case of continuous request by one device, the MUNICH32 does not generate another HOLD REQUEST before the HOLD ACKNOWLEDGE has been deactivated. User's Manual 39 01.2000 PEB 20320 Functional Description If the HOLD ACKNOWLEDGE is driven low while the MUNICH32 is performing a bus cycle, the bus is released later than two clock periods after de-assertion of HOLD ACKNOWLEDGE. The current bus cycle is finished with a bus cycle error. This action should be followed by an ASP.RES as described in Chapter 4.2.1. S1 READ S2 S1 READ S2 SW SW S1 BERR S2 SCLK A31-A2 BE(3:0) [A27-A2] W/R Tristate ADS READY BERR [DP3-DP0], D(31:0) [PCHK] ITD03501 Figure 18 Read Cycle Timing Diagram (Intel mode) User's Manual 40 01.2000 PEB 20320 Functional Description WRITE WRITE BERR SCLK A31-A2 BE(3:0) [A27-A2] Tristate W/R ADS READY BERR [DP3-DP0], D(31:0) INT [PCHK] ITD03502 Figure 19 Write Cycle Timing Diagram (Intel mode) User's Manual 41 01.2000 PEB 20320 Functional Description MUNICH32 gets the Bus Tristate HOLD (intern) Tristate Tristate Tristate ~~ HOLD (extern) HLDA No Bus requests ~~ SCLK Another Bus Master gets the Bus HLDAO Bus Cycle Max. 4 Clock Periods ITD03503 Figure 20 Bus Management for Intel Bus Mode Note 1: Bus Cycle means, that the MUNICH32 under consideration starts a read or write access at most 4 clock periods after HLDA is asserted after its HOLD. The MUNICH32 terminates the cycle typically two clock periods after the last bus cycle. Note 2: In the Bus Management example it is assumed that the MUNICH32 under consideration has a higher priority than the other bus master. HOLD (internal) is therefore the internal request generated by the MUNICH32, HOLD (external) the signal on the external HOLD line, being the OR combination of the HOLD signal generated by the MUNICH32 and the other bus master(s). Note 3: A typical configuration example for a system with several bus masters is given in Figure 4 and Figure 5. User's Manual 42 01.2000 PEB 20320 Functional Description 2.2.2 Motorola Mode In Motorola mode the bus is used in an asynchronous manner. The bus operation uses the handshake lines (AS, DS, DSACK and BERR) to control data transfer as shown in Figure 21, Figure 22. Address strobe AS indicates the validity of an address on the address bus (A31 ... A2) and of the bus definition R/W (Read or Write cycle). It is asserted half a clock cycle after the beginning of a bus cycle. The data strobe DS signal is used as a condition for valid data of a write cycle. MUNICH32 asserts DS one full clock cycle after the assertion of AS during a write cycle. The data is placed on the bidirectional data bus (D31 ... D0) half a clock cycle after AS is driven low. For a read cycle, MUNICH32 asserts DS to signal the external memory to drive the data on the bus. DS is asserted at the same time as AS during a read cycle. The data is latched with the last falling edge of the clock for that cycle. The bus cycle is terminated if the data transfer acknowledge (DSACK) is asserted with the falling edge of the third clock period. Otherwise MUNICH32 inserts wait cycles until DSACK is recognized. AS and DS are driven high half a clock period before bus cycle end. The bus error BERR is also a bus cycle termination indicator. It can be used in the absence as well as in conjunction with DSACK. If an abnormal termination has occurred during a read cycle, MUNICH32 generates an interrupt and aborts the corresponding transmit channel. For a write cycle no further action is performed. As the MUNICH32 is used in a multi-bus-master application, bus arbitration has to be done to avoid simultaneous system bus access by more than one master. In Motorola mode the bus arbitration protocol of the 68020 is established using the signals BR, BG, BGACK and BGO as shown in Figure 23. The wired-or Bus Request (BR) is driven low to indicate to the processor that one of the MUNICH32s requires control of the bus. The activated Bus Grant (BG) signals the availability of the system bus. If the MUNICH32 has activated the bus request itself, it asserts the wired-or Bus Grant Acknowledge to indicate that it has assumed bus mastership. Otherwise it will pass the BUS GRANT signal to the device cascaded next (BGO). At the same time it releases the Bus Request. After finishing the last bus cycle, the Bus Grant Acknowledge is deactivated and the Bus Grant is passed on. In order to prevent blocking in the case of continuous request by one device, MUNICH32 does not generate another Bus Request before the external Bus Request and Bus Grant Acknowledge have been deactivated. After getting the bus mastership MUNICH32 drives the bus and starts the first bus cycle one clock after assertion of BGACK. After finishing the memory access it releases the bus and de-asserts BGACK at the same time. User's Manual 43 01.2000 PEB 20320 Functional Description READ READ BERR SCLK A31-A2, BE (3:0) Tristate R/W AS DS DSACK D (31:0) BERR ITD03504 Figure 21 Read Bus Cycle Timing Diagram for Motorola Bus Mode WRITE WRITE BERR SCLK A31-A2, BE (3:0) R/W Tristate AS DS DSACK D (31:0) BERR INT ITD03505 Figure 22 Write Bus Cycle Timing Diagram for Motorola Bus Mode User's Manual 44 01.2000 PEB 20320 Functional Description MUNICH32 gets the Bus Another Bus Master gets the Bus No Bus requests SCLK ~~ Max. 4 Clock Periods BR (extern) BG ~~ BR (intern) BGACK (extern) BGACK (intern) BGO ITD03506 Figure 23 Bus Management for Motorola Mode Note: 1. In the Bus Management example it is assumed that the MUNICH32 under consideration has a higher priority than the other bus master. BR and BGACK are wired AND lines to be pulled to `1' by an external signal. 2. A typical configuration example for a system with several bus masters is given in Figure 6. User's Manual 45 01.2000 PEB 20320 Functional Description 2.2.3 DMA Priorities Prioritization of Queueing DMA Cycles Priority Interrupt Highest priority Receive link list including accesses to the descriptors Transmit link list including accesses to the descriptors Lowest priority Configuration of a channel (action requests) The MUNICH32 will perform all pending accesses on the same bus tenure. Note: Several bus transactions may be required if the MUNICH32 has not been given access to the system bus for a long period of time. This is often seen in multimaster systems where several MUNICH32 devices share the system bus. User's Manual 46 01.2000 PEB 20320 Functional Description 2.3 Basic Functional Principles MUNICH32 is a Multichannel Network Interface Controller for HDLC, offering a variety of additional features like subchanneling, data channels comprising of one or more time slots, DMI 0, 1, 2 transparent or V.110/X.30 transmission and programmable rate adaption. MUNICH32 performs formatting and deformatting operations in any network configuration, where it implements, together with a microprocessor and a shared memory, the bit oriented part (flag, bit stuffing, CRC check) of the layer 2 (data link protocol level) functions of the OSI reference model. The block diagram is shown in Figure 3. MUNICH32 is designed to handle up to 32 data channels of a 1.536/1.544 Mbit/s T1/DS1 24-channel, 2.048-Mbit/s CEPT 32-channel or a 4.096-Mbit/s 32-channel PCM highway. The device provides transmission for all bit rates from 8 Kbit/s up to 2.048 Mbit/s of packed data in HDLC format or of data in a transparent format supporting the DMI mode (0, 1, 2) or V.110/X.30 mode. Tristating of the transmission line as well as switching a channelwise or complete loop are also possible. An on-chip 64-channel DMA generator controls the exchange of data and channel control information between the MUNICH32 and the external memory. The MUNICH32 processes receive and transmit data independently for each time slot and transmission direction respectively (blocks TF = Transmit Formatter, RD = Receive Deformatter). The frame counters are reset by the rising edges of the RSP or TSP line. The processing units TF and RD work with a multiplex management, i.e. there exists only one protocol handler, which is used by all channels in a time sharing manner (see Figure 24 and Figure 25). The actual configuration, e.g. transmission mode, channel assignment, fill/mask code or state of the protocol handlers is retrieved from the Configuration and State RAM (CSR) at the beginning of the time slot and reloaded to the CSR at the end. The control unit (CD) controls the access to the CSR and allows writing of reconfiguration information only if the continuous transfer of the configuration information between the CSR and the formatters (TF and RD) will not be disturbed. In receive direction, 32 unpacked data bits are first accumulated and then stored into an on-chip receive buffer (RB) for transfer to the shared memory. As soon as the RB receives 32 bits for a channel it requests access to the parallel microprocessor bus. The on-chip transmit buffer (TB) is always kept full of data ready for transmission. The TB will request more data when 32 bits become available in the ITBS. These buffers allows a flexible access to the shared memory in order to prevent data underflow (Tx) and data overflow (Rc). The transmit buffer (TB) has a size of 64 long words (= 256 bytes). In this buffer, data of 8 PCM frames can be stored for each data channel. In this case, there are max. 1 ms between access to the shared memory and data supply to the Transmit Formatter. In order to meet these requirements a variable and programmable part of the buffer (ITBS) must be allocated to each data channel (see Figure 26). User's Manual 47 01.2000 48 Bit 1 Bit 2 ~~ ~~ Bit 0 X1 X2 X3 ~~ Active Receive Channel (external) SCLK Active Receive Channel (internal) Bit 1 Bit 0 ~~ ~~ RCLK Bit 7 ~~ Figure 24 Multiplex Management Receive Direction User's Manual RDATA X0 X1 Load CD, CSR Data for X 1 into RD RD Protocol Operation disabled RDATA CD Protocol Operation Phase of RD, CM might write new Channel Config Data into CSR CSR X2 Wait Phase no Operation of RD, CM might write new Channel Config Data into CSR RD Reload RD into CSR Protocol Operation disabled Load CSR Data for X 2 into RD RD Protocol Operation disabled RDATA CSR CD CSR X1 X2 ... X1 CSR RD CM FIFO CM RD RD 01.2000 PEB 20320 ITD04397 Functional Description CSR 49 Bit 0 ~~ ~~ ~~ ~~ Bit 7 Bit 1 Active Transmit Channel (external) X1 ~~ X0 SCLK Active Transmit Channel (internal) Bit 0 ~~ ~~ TCLK Bit 7 Bit 6 ~~ Figure 25 Multiplex Management Transmit Direction User's Manual TDATA X0 X1 Load CSR Data for X 1 into TF TF Protocol Operation disabled Protocol Operation Phase of TF, CM might write new Channel Config Data into CSR CSR Wait Phase no Operation of TF CM might write new Channel Config Data into CSR TF X2 Reload TF into CSR, CD TF Protocol Operation disabled TDATA CSR CD X1 ... X1 TF CM FIFO CM TF ITD04398 01.2000 PEB 20320 X1 X2 X0 Functional Description CSR CSR PEB 20320 Functional Description For example: a) 2.048-Mbit/s PCM highway 32 x 64-Kbit/s data channels (8 bits are sent with each PCM frame). Two long words of the buffer are allocated to each data channel. b) 1 x 2.048-Kbit/s data channel The maximum buffer size for one channel (63 long words) is allocated to this data channel. c) 6 x 256-Kbit/s and 8 x 64 Kbit/s data channels. Eight long words of the buffer are allocated to each of the 6 data channels with 256 Kbit/s and two long words are assigned to each of the 8 data channels with a transmission rate of 64 Kbit/s. The choice of the individual buffer size of each data channel can be made in the channel specification (shared memory). The buffer size of one channel is changeable without disturbing the transmission of the other channels. CD Active Transmit Channel (internal) Used as Address Offset for TB TF Unused ITBS of Channel X1 ITBS of Channel X0 ITBS of Channel X2 ITBS of Channel X3 TB 64 Long Words ITD04396 Figure 26 Partitioning of TB User's Manual 50 01.2000 PEB 20320 Functional Description The receive buffer (RB) is a FIFO buffer and also has a size of 64 long words, which allows storing the data of eight complete PCM frames before transferring to the shared memory. CD Stored in RB together with Data/Status Word from RD Active Receive Channel (internal) RD RB 64 Long Words ITD04447 Figure 27 Partitioning of RB The data transfer to the shared memory is performed via a 32-bit microprocessor interface working either in SIEMENS/Intel or Motorola bus mode. Figure 28 shows the division of the shared memory required for each MUNICH32: - - - - Configuration start address located at a programmable address Control and configuration section An interrupt circular queue with variable size Descriptor and data sections for each channel. User's Manual 51 01.2000 PEB 20320 Functional Description Receive DATA Receive DATA Interrupt Queue Receive Descriptor Receive Descriptor Receive Descriptor Transmit DATA Transmit DATA Transmit Descriptor Transmit Descriptor Transmit Descriptor Receive DATA Receive DATA ACTION SPEC. INTERRUPT QUEUE Spec. Time-Slot Assignment Channel 0 spec. CI(4:0) Control Start Address Control and Configuration section Channel 31 spec. Current Receive Descriptor Address 0 ... 31 Current Transmit Descriptor Address 0 ... 31 ACTION SPEC. INTERRUPT QUEUE Spec. Interrupt Queue Receive Descriptor Receive Descriptor Receive Descriptor Transmit DATA Transmit DATA Transmit Descriptor Transmit Descriptor Transmit Descriptor Receive DATA Receive DATA Interrupt Queue Receive Descriptor Receive Descriptor Receive Descriptor Transmit DATA Transmit DATA Transmit Descriptor Transmit Descriptor Transmit Descriptor Receive DATA Receive DATA Interrupt Queue Receive Descriptor Receive Descriptor Receive Descriptor Transmit DATA Transmit DATA Transmit Descriptor Transmit Descriptor Transmit Descriptor Time-Slot Assignment Channel 0 spec. CI(4:0) Control Start Address Control and Configuration section Channel 31 spec. Current Receive Descriptor Address 0 ... 31 Current Transmit Descriptor Address 0 ... 31 ACTION SPEC. INTERRUPT QUEUE Spec. Time-Slot Assignment Channel 0 spec. CI(4:0) Control Start Address Control and Configuration section Channel 31 spec. Current Receive Descriptor Address 0 ... 31 Current Transmit Descriptor Address 0 ... 31 ACTION SPEC. INTERRUPT QUEUE Spec. Time-Slot Assignment Channel 0 spec. Channel 31 spec. Current Receive Descriptor Address 0 ... 31 Current Transmit Descriptor Address 0 ... 31 CI(4:0) Control Start Address Control and Configuration section ITD03507 Figure 28 Memory Division for up to four MUNICH32 User's Manual 52 01.2000 PEB 20320 Functional Description The shared memory allocated for each transmit and receive channel is organized as a chaining list of buffers set up by the host. Each chaining list is composed of descriptors and data sections. The descriptor contains the pointer to the next descriptor, the start address and the size of a data section. It also includes control information like frame end indication, transmission hold and rate adaption with interframe time-fill. In the transmit direction the MUNICH32 reads a transmit descriptor, calculates the data address, writes the current transmit descriptor address into the CCS, and fills the on-chip transmit buffer. When the data transfer of the specified section is completed, the MUNICH32 releases the buffer, and branches to the next transmit descriptor. If a frame end is indicated the HDLC, TMB or TMR frame will be terminated and a specified number of the interframe time-fill byte will be sent in order to perform rate adaption. If frame end is found in a transmit descriptor TMA channel the specified number of programmable TMA flags is appended to the data in the descriptor. If frame end is found in a transmit descriptor of a V.110/X.30 channel the frame is aborted (after the data in the descriptor are sent) by finishing the current 10-octet frame with `zeros' and sending 2 more 10-octet frames with `zeros' which leads to a loss of synchronism on the peer side. An adjustment for the inserted zeros in HDLC is programmable, which leads to a reduction of the specified number of interframe time-fill by 1/8th of the number of zero insertions. This can be used to send long HDLC frames with a more or less fixed data rate in spite of the zero insertions. A maskable interrupt is generated before transmission is started again. User's Manual 53 01.2000 PEB 20320 Functional Description The following Sections give Examples of Typical Transmit Situations for the Individual Modes Variable Size Frame Oriented Protocols (HDLC, TMB, TMR) Normal operation, handling of frame end (FE) indication and hold (H) indication. Note: 1. FNUM0 must be set to zero. 2. Flag = 7EH for HDLC 00H for TMB, TMR IC = 7EH for HDLC and IFTF = 0 FFH for HDLC and IFTF = 1 00H for TMB, TMR 3. After sending the FNUM2 - 1 IC characters the device starts polling the hold bit in the transmit descriptor once for each further sent IC character. It also rereads the pointer to the next transmit descriptor once with each poll of the hold indication. The pointer to the next transmit descriptor can be changed while HOLD = 1 is set. The value of the pointer, (read in the poll where HOLD = 0) is used as the next descriptor address. If more than 6 IC characters will be sent, the use of the Transmit Hold (TH) should be considered as an alternative to using the descriptor hold bit. See Chapter 5.3.2. User's Manual 54 01.2000 User's Manual 55 Data Sections Transmit Descriptors ... Next Transmit Descr. Data 1 Next Transmit Descr. Data 2 Next Transmit Descr. FE =1 FNUM2 H =1 FNUM1+1 Flag, C, ... , C Flag FE = 1 FNUM1 H =0 Frame (Data 1, Data 2) FE=0 FNUM0 H =0 Flag Data 3 ... FNUM2 Flag, C , . . . . Frame ( Data 3 ) C Poll H=1? C, C , C , C , Flag Poll H=0 ... ... ... ITD04446 Data 4 Frame ( Data 4 ) PEB 20320 Functional Description Figure 29 01.2000 PEB 20320 Functional Description Fixed Size Frame Oriented Protocols (V110/X.30) Normal operation, E, S, X change (indicated by the V.110-bit in the transmit descriptor) Example for TRV = `11' Note: 1. FNUM must be 0 for all transmit descriptors. 2. The actual E-, S-, X-bits have to be in the first transmit descriptor after reset. 3. As shown in the example the contiguous parts of a data section belonging to one descriptor are sent in contiguous frames (DATA 1(1) are the bytes 0 - 3 of DATA 1, DATA 1(2) are the bytes 4 - 7 of DATA 1). If the end of a data section is reached within a frame, the frame is continued with data from the next data section belonging to a transmit descriptor with the bit V.110 = 0 (DATA 2(2) = byte 4 of DATA 2, DATA 3(1) = byte 0 - 2 of DATA 3). 4. The E-, S-, X-bits are only changed from one frame to the next not within a frame. The change occurs in the first frame which does not contain data of the previous data section. 5. Neither FE nor H may be set to 1 during a normal operation of the mode. They both lead to an abort of the serial interface. User's Manual 56 01.2000 User's Manual NO=2 57 Data Sections E, S, X, Next Transmit Descr. FE = 0 NO=8 H =0 V110 = 0 Data 1 Next Transmit Descr. FE=0 NO = 5 H =0 V110 = 0 10 Octets 10 Octets FE=0 H =0 Frame ( E, S, X, Data 1 (2) ) Frame ( E, S, X, Data 1 (1) ) Transmit V110=1 Descriptors Next Transmit Descr. ...00 Data 2 Next Transmit Descr. FE = 0 NO=2 H =0 V110 = 1 10 Octets Next Transmit Descr. Data 3 10 Octets ITD04444 . . . . . Frame ( E, S, X, Data 2, (2) Data 3 (1) ) FE = 0 NO=9 H =0 V110 = 0 E, S, X, Frame ( E, S, X, Data 2 (1) ) 10 Octets Frame ( E, S, X, Data 3(2) ) ... PEB 20320 Functional Description Figure 30 01.2000 PEB 20320 Functional Description Fixed Size Frame Oriented Protocols (V.110/X.30) Handling of frame end (FE) indication Note: 1. FNUM must be `0' for all transmit descriptors. 2. The frame (E, S, X, DATA 2(2)) is the beginning of a 10-octet frame. It stops with the octet no. y, containing the last data bit of DATA 2 to be sent. 3. Since y = 1, ..., 10 the 20 + y times 00H characters sent afterwards cause the peer station to recognize 3 consecutive 10-octet frames with frame error which leads to a loss of synchronism in the peer station. 4. For y = 10 DATA 2 is identical to DATA 2(1) and 30 times 00H characters are sent after frame (E, S, X, DATA 1(2), DATA 2(1)). 5. The E-, S-, X-bits are supposed to be loaded by an earlier transmit descriptor in the example. A descriptor changing them (with V.110-bit set) can be put between, before or after the descriptors in the example. It will change these bits according to the rules discussed previously. User's Manual 58 01.2000 User's Manual FE=0 H =0 59 Data Sections Data 1 10 Octets (1) Data 2 FE=0 H =0 V110 = 0 10 Octets (2) (1) Data 3 ) Frame ( E, S, X, Data 1 , Data 2 FE = 1 H =0 V110 = 0 Frame ( E, S, X, Data 1 Transmit V110 = 0 Descriptors ... ITD04448 . . . . y=1,...,10 10-y Octets ) Frame ( E, S, X, Data 2 (2) ) 20+y Octets 00,......,00 10 Octets Frame ( E, S, X, Data 3 (1) )... PEB 20320 Functional Description Figure 31 01.2000 User's Manual FE=0 H =0 10 Octets 60 Data Sections (1) FE = 1 H =1 V110 = 0 Data 2 FE=0 H =0 V110 = 0 10 Octets Data 3 ITD04449 . . . . y=1,...,10 10-y Octets (2) (1) (2) ) Frame ( E, S, X, Data 1 , Data 2 ) Frame ( E, S, X, Data 2 ) Data 1 Frame ( E, S, X, Data 1 Transmit V110 = 0 Descriptors ... 20+y Octets 00,......,00 Poll H=1? 00 00 Poll H=0 10 Octets ... 00 00 Frame ( E, S, X, Data 3 (1) ) . . . PEB 20320 Functional Description Fixed Size Frame Oriented Protocols (V110/X.30) Handling of hold (H) indication Figure 32 01.2000 PEB 20320 Functional Description Time Slot Oriented Protocol (TMA) Normal operation, handling of frame end (FE) indication and hold (H) indication. Note: 1. FNUM must be set to zero. 2. TC = FFH for TMA and FA = 0 the programmed flag with TMA and FA = 1 3. After sending the FNUM2 - 1 IC characters the device starts polling the hold bit in the transmit descriptor once for each further sent IC character. It also rereads the pointer to the next transmit descriptor once with each poll of the hold indication. The pointer to the next transmit descriptor can be changed while HOLD = 1 is set. The value of the pointer, (read in the poll where HOLD = 0) is used as the next descriptor address. If more than 6 IC characters will be sent, the use of the Transmit Hold (TH) should be considered as an alternative to using the descriptor hold bit. See Chapter 5.3.2. User's Manual 61 01.2000 User's Manual 62 Data Sections Transmit Descriptors Time-Slot Boundaries TC Data 1 Next Transmit Descr. FE=0 FNUM0 H =0 ... Data 1 Next Transmit Descr. FE = 1 FNUM1 H =0 Data 2 ... Data 2 Next Transmit Descr. FE=1 FNUM2 H =1 FNUM1+1 TC,..................,TC ... Data 3 Data 3 ... . . . . FNUM2 TC, TC,.............TC, ... Poll H=1? Poll H=0 ... TC, TC, TC,........TC, TC ... Data 4 ITD04445 Data 4 ... PEB 20320 Functional Description Figure 33 01.2000 PEB 20320 Functional Description An activated transmission hold (hold bit in descriptor) prevents the MUNICH32 from sending more data. If a frame end has not occurred just before, the current frame will be aborted and an interrupt generated. Afterwards, the interframe time-fill bytes will be issued until the transmission hold indication is cleared. There is a further transmit hold (TH) bit in the Channel Specification (CCS) in addition to the hold bit in the descriptor. Setting the transmit hold (TH) bit by issuing a channel command will prevent further polling of the transmit descriptor (see Chapter 5.3.2). This hold bit (CCS.TH) is interpreted in the CD; it causes the transmit formatter to stay in the idle state and to send interframe time-fill after finishing the current frame. In the case of a very short frame (< ITBS), this frame will stay in the TF and not be sent until CCS.TH is removed. (In case of X.30/V.110 the current frame is aborted). This means that the buffer TB is not emptied from the TF side after the current frame, but still requests further data from the shared memory until it is filled. In the case of the descriptor hold on the other hand, the TF empties the TB and there are no further data requests from the shared memory until the descriptor hold is withdrawn. Then TB is filled again and the TF is activated only after enough data are provided in the TB to prevent a data underrun. The Reaction to the Transmit Hold Bit is now Discussed for the Different Modes in the Following Sections Variable Size Frame Oriented Protocols (HDLC, TMB, TMR) Reaction to a channel specification containing TH = 1 Normal operation Note: 1. IC = 7EH for HDLC and IFTF = 1 FFH for HDLC and IFTF = 0 00H for TMB or TMR 2. flag = 7EH for HDLC 00H for TMB or TMR 3. FNUM2 is ignored. The number of interframe time-fills sent between the first frame and the second frame solely depends on the AR low pulse leading to the action with the channel with TH = 0. 4. The times t1 and t2 are statistical but typically only a few clock cycles. 5. The TH bit (as all channel commands) is not synchronized with TB! (as opposed to the H-bit in the descriptor) TH acts on the frame currently being sent, not necessarily on the last frame currently stored in the TB. In the example, TB may or may not have stored DATA 3 before the action request with TH = 1 was issued. See Chapter 4.2.5 for a further discussion of this issue. 6. If TH is handed over to CD outside of a frame, TH = 1 prevents the MUNICH32 from sending the next frame. User's Manual 63 01.2000 Figure 34 User's Manual AR t1 TH=1 in the Channel Specification handed over from CM to CD t2 TH=0 in the Channel Specification handed over from CM to CD . . . . Flag Frame ( ..., Data 1 , Data 2 ) Flag, C, C, Flag Frame ( Data 3 ) . . . . . . . 64 ... FE = 1 FNUM2 H =0 FE=0 H =0 . . . . Data 2 Data 3 01.2000 PEB 20320 ITD04450 Functional Description Data 1 PEB 20320 Functional Description Fixed Size Frame Oriented Protocol (V.110/X.30) Reaction to a channel specification containing TH = 1 Normal operation Note: 1. The times t1 and t2 are statistical but typically only a few clock cycles. 2. The current frame processed, when TH = 1 is handed over to CD is aborted, only 10 - y, (y = 1, ..., 10) octets of it are sent. The device then starts to send 20 + y 00H characters no matter how fast the TH bit is withdrawn. This ensures, that the peer site is informed about the abort with a loss of synchronism 3. The data section DATA 1 is split in the example; DATA 1(1) is sent in the aborted frame, all bits that were read into the MUNICH32 with the same access are discarded (they would have been sent in the next frame(s) if TH = 1 was not issued) and the device starts the next frame with the bits DATA 1(3) of the access to DATA 1 that follows the one getting the bits of DATA 1(1). 4. The TH (as all channel commands) is not synchronized with TB. TH acts on the frame currently sent, not necessarily on the last stored data. 5. If TH is handed over to CD before a frame has started after an abort or after reset no frame will start. User's Manual 65 01.2000 PEB 20320 Functional Description AR t1 ... Frame ( E, S, X, Data 1 (1) ) TH=1 in the Channel Specificaton handed over from CM to CD 00 ... 00 10-y Octets ... TH=0 in the Channel Specificaton handed over from CM to CD t 2 ........... 00 ... 00 20+y Octets Frame ( E, S, X, Data 1 (3) ) . . . 10 Octets FE= 0 H =0 . . . . Data 1 ITD04454 Figure 35 Time Slot Oriented Protocol (TMA) Reaction to a channel specification containing TH = 1 Note: 1. TC is the programmed TFLAG for FA = 1 FFH for FA = 0 2. The times t1 and t2 are statistical but typically only a few clock cycles. 3. The TH bit (as all channel commands) is not synchronized with the TB! (as opposed to the H-bit in the descriptor) TH acts to the data stream currently sent. User's Manual 66 01.2000 Figure 36 User's Manual AR t1 TH=1 in the Channel Specification handed over from CM to CD t2 TH=0 in the Channel Specification handed over from CM to CD Time-Slot Boundaries Data 1 , Data 2 , TC, . . . . TC, TC, TC, Data 3 . . . 67 FE= 0 FNUM0 H =0 FE = 1 H =0 ... . . . . Data 2 Data 3 01.2000 PEB 20320 ITD04452 Functional Description Data 1 PEB 20320 Functional Description Variable Size Frame Oriented Modes (HDLC, TMB, TMR) Reaction to a channel specification containing TH = 1 Silencing of poll cycles for hold. Note: An AR pulse for an action specification leading to TH = 1 should be issued after (ITBS + 2) polls of the MUNICH32, where ITBS is the previously programmed number of long words in the TB reserved for this channel. User's Manual 68 01.2000 Figure 37 User's Manual AR t1 TH=1 in the Channel Specification handed over from CM to CD t2 TH=0 in the Channel Specification handed over from CM to CD . . . . Flag Frame ( ..., Data 1 ) Flag, C, ... , C, C, ... C, . . . . C, C, C , ... C, Flag Frame ( Data 2 ) . . . ... FNUM0 Poll H=1? ... No Poll Poll H=1? Poll H=0 69 ... FE= 1 FNUM0 H =1 . . . . Data 2 01.2000 PEB 20320 ITD04451 Functional Description Data 1 PEB 20320 Functional Description Fixed Size Frame Oriented Protocol (V110/.30) Silencing of poll cycles by TH = 1 Note: 1. The times t1 and t2 are statistical but typically only a few clock cycles. 2. The TH bit (as all channel commands) is not synchronized with TB! (as opposed to the H-bit in the descriptor) TH acts to the data stream currently sent. 3. In the example the proper use to silence a channel polling the HOLD bit of the transmit descriptor is illustrated. The AR pulse is issued after the polling has started and the H-bit is not reset before polling has stopped by the TH bit. 4. An AR pulse for an action specification leading to TH = 1 should be issued after (ITBS + 2) polls of the MUNICH32, where ITBS is previously programmed number of long words in the TB reserved for this channel. User's Manual 70 01.2000 Figure 38 User's Manual AR t 1 Frame ( E, S, X, Data 1 (1) ) Frame ( E, S, X, Data 1 (2) ) 00 ... 00 TH=1 in the Channel Specif. handed over to CD t 2 ........... TH=0 in the Channel Specif. handed over from CM to CD 00 ... 00 10-y Octets 10 Octets Frame ( E, S, X, Data 2 (1) ) . . . 10 Octets Poll H=1 H=1 No Poll Poll H=1 H=0 71 20+y Octets ... FE= 1 H =1 . . . . Data 2 01.2000 PEB 20320 ITD04455 Functional Description Data 1 PEB 20320 Functional Description Time Slot Oriented Protocol (TMA) Reaction to a channel specification containing TH = 1 Note: 1. TC = FFH for TMA and FA = 0 the programmed flag for TMA and FA = 1 2. FNUM2 is ignored. The number of interframe time-fills between the first frame and the second frame solely depends on the AR low pulse leading to the action with the channel with TH = 0. 3. The times t1 and t2 are statistical but typically only a few clock cycles. 4. The TH bit (as all channel commands) is not synchronized with TB (as opposed to the H-bit in the descriptor) TH acts on the data stream currently sent not necessarily on the last data stored in TB. In the example TB may or may not have stored DATA 3 before action request with TH = 1 was issued. 5. The data stream is stopped and TC sent after the last byte of DATA 2 is sent. The stopping is triggered by the FE = 1 bit in the descriptor. 6. If TH is bonded over to CD during interframe time-fill (TC) it prevents the MUNICH32 from sending further data afterwards. 7. An AR pulse for an action specification leading to TH = 1 should be issued after (ITBS + 2) polls of the MUNICH32, where ITBS is previously programmed number of long words in the TB reserved for this channel. User's Manual 72 01.2000 Figure 39 User's Manual AR t1 TH=1 in the Channel Specification handed over from CM to CD t2 TH=0 in the Channel Specification handed over from CM to CD . . . . ... Data 1 , TC, TC, ... , TC, TC, . . . . ... TC, TC, TC, TC , ... TC, ... FNUM0 Poll H=1? Data 2 . . . ... No Poll Poll H=1? Poll H=0 73 ... FE= 1 FNUM0 H =1 . . . . Data 2 01.2000 PEB 20320 ITD04453 Functional Description Data 1 PEB 20320 Functional Description In receive direction the MUNICH32 reads a receive descriptor, calculates the data address, writes the current receive descriptor address into the CCS, and exchanges data between the on-chip receive buffer and the external memory. After the data section has been filled, the MUNICH32 writes the number of stored bytes (BNO) into the descriptor. If a frame end has occurred the frame status is written into the descriptor and an interrupt is generated. The frame status includes the CRC check results and transmission error information like `non octet of bits', `aborted frame', `data overflow', `maximum frame length exceeded' and `frames with less than or equal to two data bytes'. An activated reception-hold in the descriptor prevents the MUNICH32 from processing the receive data. The incoming frames are discarded until the hold is deactivated. Because the MUNICH32 is divided into two non-synchronized parts by the on-chip buffers, two different kinds of aborting a channel transmission are implemented. - Normal abort: This abort of a receive or transmit channel is processed in the formatters of the serial interface. The interframe time-fill code is sent after aborting the current issued frame. No accesses to the on-chip buffers are carried out, until the abort is withdrawn. The handling of the link lists and the processing of the buffers by the DMA controller are not affected by normal abort. - Fast abort: A fast abort is performed by the DMA controller and does not disturb the transmission on the serial interface. If this abort is detected the current descriptor is suspended with an abort status immediately followed by a branching to the new descriptor defined in the channel specification of the CCS. For initialization and control the host sets up a Control and Configuration Section (CCS), including the action specification, interrupt queue specification, time slot assignment and the channel specification. The host initiates an action, e.g. reconfiguration, change of the channel mode, reset or switching of a test loop by updating the CCS and issuing an action request pulse. When the action request pulse is detected by the MUNICH32 it reads the control start address, then the action specification and, if necessary, additional information from the CCS. After execution, the action request is acknowledged by an interrupt. MUNICH32 indicates an interrupt by activating the interrupt line and storing the interrupt information including the corresponding channel number in the interrupt queue. The interrupt queue is a circular buffer; MUNICH32 starts to write the interrupt queue specification and fills it successively in a circular manner. The host has to allocate sufficient buffer size and to empty the buffer fast enough in order to prevent overflow of the queue. User's Manual 74 01.2000 PEB 20320 Functional Description Monitoring functions are implemented in MUNICH32 to discover errors or condition changes, i.e. - Receive frame end - Receive frame abort by overflow of the receive buffer or hold condition or recognized ABORT flag - Frame overflow, if a frame has to be discarded because of pending inaccessibility of the chip memory - Transmit frame end - Transmit frame abort (data underrun) by underrun of the transmit buffer or hold condition or bus cycle error - Change of the interframe time-fill. - Loss of synchronism or change of framing bits (V.110, X.30). - Short frame with no data content detected. An error or condition change is indicated by an interrupt. The host may react to the interrupt by either aborting or tristating the specific channel or with a channel reconfiguration. To prevent underrun of the transmit buffer sufficient buffer size has to be allocated to the channel. A more detailed discussion of the receive procedure with examples is provided under the detailed protocol description in Chapter 2.4. User's Manual 75 01.2000 PEB 20320 Functional Description 2.4 Detailed Protocol Description In the following sections the protocol support of the MUNICH32 is described in detail for transmit and receive direction separately. Each section starts with a discussion of the general features proceeds with protocol variants and options from the channel specification and closes with a description of the interrupts and special topics. HDLC Transmit Direction General Features In transmit direction - - - - the starting and ending flag (7EH before and after a frame) the interframe time-fill between frames the zero insertions (a `0'-bit after 5 consecutive `1's inserted within a frame) (optional) the Frame Check Sequence (FCS) at the end of a frame is generated automatically. Options The different options for this mode are - the kind of the interframe time-fill character in the channel specification - 7EH for IFTF = 0 - FFH for IFTF = 1 - the number of interframe time-fill characters as FNUM in the transmit descriptor. For the values FNUM = 0, 1, 2 we have - FNUM = 0 frame 1, 7EH, frame 2 (start flag = end flag) - FNUM = 1 frame 1, 7EH, 7EH, frame 2 - FNUM = 2 frame 1, 7EH, IC, 7EH, frame 2 - the correction of the number of interframe time-fill characters by 1/8 of the number of zero insertions by programming FA in the channel specification. - FA = 0: FNUM from the transmit descriptor is taken directly to determine the number of interframe time-fill characters as shown in Figure 39. - FA = 1: FNUM from the transmit descriptor is reduced by 1/8 of the number of the zero insertions of the frame corresponding to the transmit descriptor as shown in Figure 40. This allows for a more or less constant bit rate transmission for long HDLC frames. User's Manual 76 01.2000 PEB 20320 Functional Description 7 EH Frame 1 7 EH . . . . . . 7 EH Frame 2 x Zero Insertions y= max (FNUM - [ FE=1 y+1 x ], 0) 8 FNUM Data Contents of Frame 1 Data Contents of Frame 2 ITD04579 Figure 40 x x --- is the biggest integer smaller than --- . 8 8 x 1. For FNUM - --- < 0, y = 0 8 Note: 1. - the kind of Frame Check Sequence (FCS) two kinds of frame check sequences are implemented by the CRC bit in the channel specification CRC = 0: the generator polynomial x16 + 12 + x5 + 1 is used (2 byte FCS of CCITT Q.921) CRC = 1: the generator polynomial x32 + x26 + x23 + x22 + x16 + x12 + x11 + ... ... x10 + x8 + x7 + x5 + x4 + x2 + x + 1 (4 byte FCS) is used - the suppression of the automatic generation of the FCS is programmable in the channel specification: - CS = 0: FCS generated automatically CS = 1: FCS generation suppressed and in the transmit descriptor CSM = 0: FCS generated automatically if CS = 0 in the channel specification CSM = 1: FCS generation suppressed User's Manual 77 01.2000 PEB 20320 Functional Description Interrupts The possible interrupts for the mode in transmit direction are: HI: issued if the HI bit is detected in the transmit descriptor (not maskable) FI: issued if the FE bit is detected in the transmit descriptor (maskable by FIT in the channel specification) ERR: one of the following transmit errors has occurred: - the last descriptor had H = 1 and FE = 0 - the last descriptor had NO = 0 and FE = 0 (maskable by TE in the channel specification) FO: one of the following transmit errors have occurred - a BERR = `0' was detected during a read access to a transmit data section for this channel - the MUNICH32 was unable to access the shared memory in time either for new data to be sent or for a new transmit descriptor. (maskable by TE in the channel specification) typical data stream has the form ... ITF FLAG DATA FCS FLAG ITF ... Example: HDLC channel with CS = 0) (FCS generated automatically) INV = 0 (no inversion) CRC = 0 (CRC16) TRV = 00 (required as unused in HDLC mode) FA = 1 (flag adjustment) MODE = 11 (HDLC) IFTF = 1 (interframe time-fill `1's) INTEL interface Channel number 1A User's Manual 78 01.2000 PEB 20320 Functional Description Generate FI, HI-Int. 2000181A Generate FI-Int. 2000081A Generate FI-Int. 2000081A 1st Desc 31 0 2 nd Desc 31 0 3 rd Desc 31 0 A0010002 80060801 80030800 0 0 31 0 31 0 FF FF FF FF 0 AA 00 FF FE=1 HOLD=0 HI=1 NO=1 CSM=0 FNUM=2 FLAG 0 FA 28 AA Address FE=1 Increases HOLD=0 HI=0 NO=3 CSM=1 FNUM=0 FE=1 HOLD=0 HI=0 NO=6 CSM=1 FNUM=1 Time Increases 31 Zero Insertion DATA 1 1 FCS 2 FLAG ITF 3 ..... 01111110 01010101 00010100010111110 01111110 11111111 8 Zero Insertion 4 DATA 2 FLAG FLAG 5 01111110 111110111110111110111110111110111110111110111110 00000000 01111110 Zero Insertion DATA 3 FLAG 0101010100010100010111110 01111110 ITD04578 Figure 41 Note: 1. Data is transmitted according to 2.8 of CCITT recommendation Q.921 2. Note: FCS in the data section is formatted as ordinary data!!! 3. FCS is generated here automatically as CS = 0 and CSM = 0 for the 1st descriptor. 1 4. There was 1 zero insertion in the 1st frame, so FNUM - --- = FNUM = 2. 8 Therefore between the first and the second frame we have FLAG ITF FLAG and ITF = FFH because IFTF = 1. User's Manual 79 01.2000 PEB 20320 Functional Description 5. No FCS is generated here as CSM is `1' for the second and third transmit descriptor. The FCS is supposed to be the last 2 bytes to be transmitted in this case, their validity is not checked internally. 6. There was 8 zero insertions in the 2nd frame, so FNUM - Therefore between the second and the third frame we have a shared FLAG. 8 --8 = FNUM - 1 = 0. For CS = 1 (CRC select) the transmitted data stream would differ at FCS, FCS would just be omitted. For INV = 1 (channel inversion) all bits of the data stream (including FLAG, DATA, FCS, ITF) would be inverted. For CRC = 1 (CRC 32) the transmitted data stream would only differ in the FCS, the FCS would be 1101 0111 1010 0101 1000 0000 0010 0111. For FA = 0 (no flag adjustment) the transmitted data stream would change only after DATA 2. The value FNUM = 1 in the second descriptor would alone determine the number of interframe time-fill characters, the scenario would look like DATA 2 FLAG 0111 111 FLAG DATA 3 0111 111 Figure 42 For IFTF = 0 (ITF flags) the transmitted data stream would only differ at ITF, the 8 ones would be replaced by 0111 1110. For Motorola interface the only difference is in the data section For the first descriptor it ought to be 31 0 AA and for the second 31 0 FF FF FF FF FF 00 and for the third 31 AA 28 0 FA User's Manual 80 01.2000 PEB 20320 Functional Description HDLC Receive Direction General Features In receive direction: 1. The starting and ending flag (7EH before and after a frame) is recognized and extracted. 2. A change of the interframe time-fill is recognized and reported by an interrupt. 3. The zero insertions (a `0'-bit after five `1's within a frame) are extracted. 4. The FCS at the end of a frame is checked, it is (optionally) transferred to the shared memory together with the data. 5. The number of the bits within a frame (without zero insertions) is checked to be divisible by 8. 6. The number of bytes within a frame is checked to be smaller than MFL + 1 (after extraction of `0' insertions). 7. The number of bits within a frame after extraction of `0' insertions is checked to be greater than (case NSF = 0 only) (case NSF = 0 only) check a) (only for CS = 0) check b) 16 for CRC = 0 32 for CRC = 1 32 for CRC = 0 48 for CRC = 1 (case NSF = 1 & CS = 1 only) check a') 8 for CRC = x (ignored) 8. The occurrence of an abort flag (7FH) ending a frame is checked. More detailed description of the individual features: 1. a. A frame is supposed to have started if after a sequence of 0111 1110 in the receive data stream neither FCH nor FDH nor 7EH has occurred. The frame is supposed to have started with the first bit after the closing `0' of the sequence. b. A frame is supposed to have stopped if a sequence of 0111 1110 or 0111 1111 is found in the data stream after the frame has started. The last bit of the frame is supposed to be the bit preceding the `0' in the above sequences. The cases of sequences 0111 1110 1111 111 and 0111 1110 0111 1111 are also supposed to be frames of bit length - 1 and 0 respectively. A frame is also supposed to have stopped if more than MFL bytes were received since the start of the frame and it wasn't stopped yet. c. The ending flag of a frame may be the starting flag of the next frame (shared flags supported). User's Manual 81 01.2000 PEB 20320 Functional Description 2. The receiver is always in one of two possible interframe time-fill states: to be called F and O. The following diagram explains them. A change from F to O and from O to F is reported by an IFC interrupt. RESET or Receive OFF Receive Initialize Channel Command O 011111101111110 or 0111111001111110 in the Data Stream (2 contiguous Flags received, Flags with shared Zeros supported) F 111111111111111 in the Data Stream (15 contiguous "1"s received) or a Receive Abort Channel Command during 15 received Bits ITD04577 Figure 43 3. The `0' extraction is also carried out for the last 6 bits before the stopping sequence. 4. The last 16 (CRC = 0) or 32 (CRC = 1) bits of a frame (after extraction of the zero insertions are supposed to be the FCS of the remaining bits of the frame. (For the case of a frame with less than or equal to 16 or 32 bits respectively see discussion of 7). The FCS is always checked, the check is reported in the CRCO bit of the last receive descriptor of the frame CRCO = 1: FCS was incorrect CRCO = 0: FCS was correct. 5. The check is reported in the NOB bit in the last receive descriptor of the frame NOB = 1: The bit length of the frame was not divisible by 8. NOB = 0: The bit length of the frame was divisible by 8. If NOB = 1: The last access to a receive data section of the frame may contain erroneous bits and shouldn't be evaluated. 6. The check is reported in the LFD bit in the last receive descriptor of the frame. LFD = 1: The number of bytes was greater than MFL. LFD = 0: The number of bytes was smaller or equal to MFL. Only the bytes up to the MFL + 1st one for CS =1 MFL - 1st one for CS = 0, CRC = 0 MFL - 3rd one for CS = 0, CRC = 1 are transferred to be stored memory. The bytes of the last access may be erroneous and shouldn't be evaluated. User's Manual 82 01.2000 PEB 20320 Functional Description 7. For frames not fulfilling check a) no data are transferred to the shared memory irrespective of CS. Only an interrupt with the bit FI, SF and (possibly) ERR is generated. For frames fulfilling check a) but not check b) data is transferred to the shared memory but the SF bit in the last receive descriptor is set. 8. The check is reported in the RA bit in the last receive descriptor of the frame RA = 1: The frame was stopped by the sequence 7FH RA = 0: The frame was not stopped by the sequence 7FH. Note: A receive descriptor with RA = 1 may also result from a fast receive abort or a receive abort channel command or from a receive descriptor with set HOLD bit. Options The different options for this mode are: - The kind of Frame Check Sequence (FCS) Two kinds of FCS are implemented and can be chosen by CRC bit. CRC = 0: the generator polynomial x16 + x12 + x5 + 1 is used (2 byte FCS of CCITT Q.921) CRC = 1: the generator polynomial x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 (4 byte FCS) is used. - the transfer of the FCS together with the received data is programmable by the CS bit. CS = 0: FCS is not transferred to the data section CS = 1: FCS is transferred to the data section. Note: FCS is always checked irrespective of the CS bit. Interrupts The possible interrupts for the mode in receive direction are: HI: issued if the HI bit is detected in the receive descriptor (not maskable) FI: issued if a received frame has been finished as discussed in 1.b of the protocol features (also for frames which do not lead to data transfer as discussed in 7. of the protocol features) (maskable by FIR in the channel spec.) IFC: issued if a change of the interframe time-fill state as discussed in 2. has occurred. (maskable by IFC in the channel spec.) SF: a frame not fulfilling check a) has been detected (maskable by SFE in the channel spec.) User's Manual 83 01.2000 PEB 20320 Functional Description ERR: issued if one of the following error conditions has occurred: - FCS was incorrect - the bit length was greater than MFL - the frame was stopped by 7FH - the frame could only be partly stored because of internal buffer overflow of RB - a fast receive abort channel command was issued - a receive abort channel command was detected during reception of a frame - a frame could only be partly transferred to the shared memory because of a receive descriptor with HOLD bit set (maskable by RE in the channel spec.) FO: issued if due to inaccessibility of internal buffer RB - one ore more complete frames have been lost - one ore more changes of interframe time-fill state were lost (maskable by RE in the channel spec.) Example: HDLC channel with CS = 1 (FCS transferred to shared memory) INV = 0 (no inversion) CRC = 1 (CRC 32) TRV = 00 (required as unused in HDLC mode) FA = x (irrelevant) MODE = 11 (HDLC) IFTF = x (irrelevant) Motorola interface Channel No. 1D MFL = 10 User's Manual 84 01.2000 PEB 20320 Functional Description FLAG ..... 1 DATA 1, FCS 1 01111110 0100 0011 1000 0101 1000 0000 1100 0000 1001 1100 0000 0001 10111100 2 DATA Ignored up to next Flag 0011 1101 0011 11100 0011 1000 0110 0011 1101 1011 0010 0100 Abort Sequence 3 01111111 Generate HI-Int. 8800203D 1st Desc 31 0 2 nd Desc 31 4 0 000C0000 C0031C00 20080000 40080000 DATA 2 Generate FI, ERR-Int. 8800123D 31 0 C2 A1 01 03 39 80 3D BC 31 0 CRCO, NOB, LFD 5 Last Access of a LFD Frame should be Ignored ITD04576 Figure 44 User's Manual 85 01.2000 PEB 20320 Functional Description Zero Insertion FLAG 01111110 (shared) FLAG 01111110 DATA 2 0000 0000 0011 0101 1001 0010 1101 1111 0 Zero Insertion FCS 2 0000 0011 0010 0101 0100 1111 0101 1111 0 Zero Insertion 6 DATA 3 0000 0000 0011 0101 1001 0010 1101 1111 0 Zero Insertion Missing FCS 3 0000 0011 0010 0101 0100 1111 0101 1111 FLAG 01111110 Generate FI, HI-Int. 8800303D 3 rd Desc 31 0 4 th Desc 31 0 200C0000 C0080000 000C0000 C0081800 DATA 2 31 0 00 AC 49 FB FCS 2 C0 A4 F2 FA CRCO, NOB Generate FI, ERR-Int. 8800123D 31 0 00 AC 49 FB DATA 3 ITD04575 Last Access of a NOB Frame should be Ignored Figure 45 User's Manual 86 01.2000 PEB 20320 Functional Description FCS 4 DATA 4 0101 0101 1101 1110 1010 0101 1000 0000 0010 0111 2 Flags with shared 0 FCS 5 0111 1110 111 1110 FLAG 01111110 0000 0000 0000 0000 0000 0000 0000 0000 FCS 6 DATA 6 Abort Sequence 0101 0101 1101 1110 1010 0101 1000 0000 0010 0111 DATA Ignored up to next Flag FLAG 01111110 01111111 15 x "1" 7 1 1111110101000110011100111010 0111 1111 1111 1111 01110 011111100011111101111111 Generate FI-Int. 8800103D Generate IFC-Int. (2 Flags) 8800083D Generate short Frame Interrupt for FCS 5 8800143D 9 10 5 5 th Desc 31 0 6 th Desc 31 0 000C0000 C0050000 00140000 C0050200 DATA 4 FCS 4 8 31 0 AA 7B A5 01 E4 XX XX XX 12 RA Generate FI, ERR-Int. 8800123D Generate IFC-Int. 11 (15 * 1) 8800083D Generate Short Frame Interrupts 8800163D 8800163D 31 0 AA 7B A5 01 E4 XX XX XX ITD04574 Figure 46 Note: 1. After Receive Initialization is detected all data are ignored until a flag is received. The receiver is in the interframe time-fill state `0'. 2. After MFL + 1 data bytes are received the further data are ignored (except for a change of the interframe time-fill state) and are neither stored in the RB nor reported to the shared memory. The receiver waits for the next flag. 3. Even the abort sequence at the end of the frame will not lead to the RA bit in the descriptor to be set. 4. Data are formatted according to 2.8 of CCITT Q.921. 5. The FCS is formatted as ordinary data!!! User's Manual 87 01.2000 PEB 20320 Functional Description 6. LFD is issued and always accompanied by NOB. CRCO shouldn't be interpreted for a LFD frame. 7. Here the ending flag of the second frame is the starting flag of the third frame. 8. After an abort sequence data is ignored until a flag is found (except for a change of the interframe time-fill state). They are neither stored in the RB nor reported to the shared memory. 9. The last 3 bytes in the last write access to the receive data section of the 5th descriptor have to be ignored. 10.The 2 flags with a shared 0 in the middle change the original interframe timefill state `0' of the receiver to `F'. The 2 flags following FCS 5 on the other hand do not change the interframe time-fill state, as it already was `F'. 11.The frame consisting only of 32 times 0 between 2 flags does not pass check a). It only leads to an interrupt. 12.The 15 x `1' leads to a change of the interframe time-fill state from `F' to `0' even through it is in a data ignored zone. 13.This frame of length - 1 leads to an interrupt. For CS = 0 (CRC not select) the descriptor would have looked like Generate HI, FI, ERR-Int. 8800323D 1st Desc 1 31 0 3 rd Desc 2 31 0 20080000 C0071C00 200C0000 C0040000 31 0 C2 A1 01 03 Generate HI, FI-Int. 8800303D 31 0 00 AC 49 FB ITD04572 Last Access of a LFD Frame should be Ignored Figure 47 User's Manual 88 01.2000 PEB 20320 Functional Description Generate FI, ERR-Int. 8800123D Interrupts as in the original Example 4 th Desc 31 0 5 th Desc 31 0 6 th Desc 31 0 000C0000 C0041800 000C0000 C0014000 00140000 C0014200 31 CRCO, NOB 0 SF 31 0 AA XX XX XX SF, RA 31 0 AA XX XX XX ITD04573 Last Access of a NOB Frame should be Ignored Figure 48 Note: 1. Only the 7 leading bytes are reported (the last 4 are supposed to be the FCS even in this case). 2. It is assumed here for convenience that the first descriptor points to the third and not to the second descriptor as in the original example. For INV = 1 (channel inversion) all bits of the data stream (including DATA, FCS, flag, abort sequence 15 x `1') are interpreted inversely. e.g. `1000 0001' would be interpreted as flag 15 x `0' would lead to a change from interframe time-fill state `F' to `0' etc. User's Manual 89 01.2000 PEB 20320 Functional Description For CRC = 0 (CRC 16) the correct FCS e.g. zeros for DATA 4 would be 00001 0100 0101 1110 the 5th descriptor would then be 5 th Desc 31 0 000C0000 C0034000 31 0 AA 28 FA XX ITD04570 Figure 49 For Intel interface the only difference is in the receive data sections. They would be of 1st Desc 31 0 03 01 A1 C2 BC 30 80 39 of 3 rd Desc 31 0 FB 49 AC 00 FA F2 A4 C0 of 5 th Desc 31 0 01 A5 7B AA XX XX XX E4 ITD04571 Figure 50 User's Manual 90 01.2000 PEB 20320 Functional Description TMB Transmit Direction General Features In transmit direction: - The starting and ending flag (00H before and after a frame) - The interframe time-fill between frames is generated automatically. Options The different options for this mode are: - The number of interframe time-fill characters as shown in Figure 26 by choosing FNUM in the transmit descriptor. For the values FNUM = 0, 1, 2 we have FNUM = 0 FNUM = 1 FNUM = 2 ... frame 1, 00H, frame 2 ... (start = end flag) ... frame 1, 00H, 00H, frame 2 ... ... frame 1, 00H, 00H, 00H, frame 2 ... Interrupts The possible interrupts for the mode in transmit direction are identical to those of HDLC. A typical data stream has the form ITF DATA ITF DATA Example TMB channel with INV = 0 (no inversion) CRC = 0 (required) TRV = 00 (required) FA = 0 (required) MODE = 01 (TMB) IFTF = 0 (required) Intel interface Channel number 5 User's Manual 91 01.2000 PEB 20320 Functional Description Generate FI-Interrupt 88001005 Generate HI-Interrupt 88002005 2 31 31 0 20020000 Generate FI-Interrupt 88001005 3 0 31 80000000 0 80030001 0 0 31 31 0 CE AB 0 45 23 01 1 FLAG ..... 0 0 DATA 1 FLAG DATA 2 2 FLAGS D 5 7 3 0 0 8 0 C 4 A 2 0 0 0 0 ..... ITD04569 Figure 51 Note: 1. Data is transmitted according to Q.921 2.8 and fully transparent. 2. A transmit descriptor with NO = 0 and FE = 1 is allowed, one with NO = 0 and FE = 0 is forbidden. 3. FNUM = 1 leads to 2 FLAGS after DATA 2. User's Manual 92 01.2000 PEB 20320 Functional Description TMB Receive Direction General Features 1. The starting and ending flag (00H before and after a frame) as well as interframe timefill is recognized and extracted. 2. The number of bits within a frame is checked to be divisible by 8. 3. The number of bytes within a frame is checked to be smaller than MFL + 1. 4. A frame containing less than 8 bits may be ignored completely by the receiver. More detailed description of the individual features: 1. a. A frame is supposed to have started if after a sequence `0000 0000' a `1'-bit is recognized. The frame is supposed to have this `1'-bit as first bit. b. A frame is supposed to have stopped if - either a sequence 0000 0000 1 is found in the data stream after the frame has started - or a sequence 0000 0000 is found octet synchronous (i.e. the first bit of the sequence 00H is the 8 m + 1st bit since the starting `1'-bit of 1.a. for an integer m). In both cases the last bit before the sequence 00H is supposed to be the last bit of the frame. 2. The check is reported in the NOB bit in the last receive descriptor of the frame. NOB = 1: The bit length of the frame was not divisible by 8. NOB = 0: The bit length of the frame was divisible by 8. 3. The check is reported in the LFD bit in the last receive descriptor of the frame. LFD = 1: The number of bytes was greater than MFL. LFD = 0: The number of bytes was smaller or equal to MFL. Only the bytes up to the MFl + 1st one are transferred to the shared memory. The bytes of the last access to the receive data section of the frame may contain erroneous bits and shouldn't be evaluated. LFD is always accompanied by NOB. Options There are no options in receive direction for this mode. User's Manual 93 01.2000 PEB 20320 Functional Description Interrupts The possible interrupts for the mode in receive direction are: HI: issued if HI bit is detected in the receive descriptor (not maskable). FI: issued if a received frame has been finished as discussed in 1b) of the protocol features or a receive abort channel command was detected during reception of a frame. (maskable by FIR in the channel spec.) ERR: issued if one of the following error conditions has occurred - the bit length of the frame was not divisible by 8 - the byte length was greater than MFL - the frame could only be partly stored because of internal buffer overflow of RB - a fast receive abort channel command was issued - the frame could only be partly transferred due to a receive descriptor with set HOLD bit. (maskable by RE in the channel specification) FO: issued if due to inaccessibility of the internal buffer RB one or more complete frames have been lost. (maskable by RE in the channel spec.) Example: TMB channel with INV = 0 (no inversion) CRC = 0 (required) TRV = 00 (required) FA = 0 (required) MODE = 01 (TMB) IFTF = 0 (required) MFL = 7 Motorola interface Channel No. A User's Manual 94 01.2000 PEB 20320 Functional Description FLAG DATA 1 1 00000000 10111001 10000000 octet synchronous FLAG 3 00000000 00 octet synchronous FLAG DATA 2 11001011 00000000 DATA 3 10000000 (start) FLAG non octet synchronous FLAG 10111100 0000000 4 DATA 4 10000000 11111110 01111111 11111011 11010101 01001100 DATA Ignored up to next Framestart 5 FLAG 10100000 11110111 01010101 Generate FI, 8800302A Generate FI-Int. 8800102A DATA 5 0000 0000 0000 10101101 HI-Int. 1 st Desc 31 0 2 nd Desc 31 0 3 rd Desc 31 0 00040000 C0020000 200C0000 C0010000 20080000 C0020800 DATA 1 2 31 0 9D 01 XX XX 31 0 DATA 2 D3 XX XX XX FLAG 00101010 0000 0000 Generate FI, 8800322A HI, ERR-Int. 31 NOB 0 ITD04568 DATA 3 Last Access of a NOB Frame should be Ignored Figure 52 User's Manual 95 01.2000 PEB 20320 Functional Description Generate FI, 8800122A Generate HI-Int. 8800202A 4 th Desc 31 0 5 th Desc 6 31 0 6 th Desc 31 0 20080000 40080000 00040000 C0000C00 00FC0000 C0020000 DATA 4 31 0 01 7F FE DF LFD, NOB Generate FI-Int. 8800102A ERR-Int. DATA 5 31 0 B5 54 XX XX ITD04567 Last Access of a LFD Frame should be Ignored Figure 53 Note: 1. After Receive Initialization is detected all data are ignored until the starting sequence 0000 0000 1 is detected. 2. Data are formatted according to 2.8 of CCITT Q.921. 3. The octet synchronous (end) flag of one frame can be part of the (start) flag of the next frame. Between DATA 1 and DATA 3 they are identical (shared flags supported). 4. Here the sequence 0000 0000 1 is detected non-octet synchronously. Therefore the frame belonging to DATA 3 is supposed to have ended non-octet synchronously (NOB set in the 3rd descriptor). 5. After MFL + 1 data bytes the further data are ignored and are neither stored in the RB nor reported to the shared memory. The receiver waits for the next sequence 0000 0000 1 to come. 6. If a receive descriptor is full (4th desc.) the MUNICH32 branches to the next receive descriptor (5th desc.) even if no further data are to be given to the shared memory. User's Manual 96 01.2000 PEB 20320 Functional Description For INV = 1 (channel inversion) all bits of the data stream (including DATA, FLAG) are interpreted inversely e.g. 1111 1111 0 would be interpreted as starting sequence then. For Intel interface the only difference is in the receive data sections. They would be of 1st Desc 31 0 XX XX 01 9D of 2 nd Desc 31 0 XX XX XX D3 of 4 th Desc 31 0 DF FE 7F 01 of 6 th Desc 31 0 XX XX 54 B5 ITD05034 Figure 54 User's Manual 97 01.2000 PEB 20320 Functional Description TMR Transmit Direction General Features In transmit direction - the starting and ending flag (00 00H or 0 00H between frames) is generated automatically. Options The different options for this mode are - the number of interframe time-fill characters as shown in Figure 29 by choosing FNUM in the transmit descriptor. For the values 0, 1, 2 we have FNUM = 0 FNUM = 1 FNUM = 2 ... frame 1, 000H, frame 2 ... ... frame 1, 00H, 00H, frame 2 ... ... frame 1, 00H, 00H, 00H, frame 2 ... By choosing FNUM = 0 and setting the last transmitted nibble in the transmit data section to 0H frames of effective length n + 1/2 bytes can be sent as required by GSM 08.60. Interrupts The possible interrupts for the mode in the transmit direction are identical to those of HDLC. A typical data stream has the form ITF DATA ITF DATA Example: TMR channel with INV = 0 (no inversion) CRC = 1 (required) TRV = 00 (required) FA = 0 (required) MODE = 01 (TMR) IFTF = 0 (required) Intel interface Channel No. 5 User's Manual 98 01.2000 PEB 20320 Functional Description Generate FI-Interrupt 88001005 Generate HI-Interrupt 88002005 2 31 31 0 20020000 Generate FI-Interrupt 88001005 3 0 31 80000000 0 80030001 0 0 31 31 0 0E AB 0 45 23 01 1 FLAG ..... 0 0 DATA 1 FLAG DATA 2 2 FLAGS ITD04566 D 5 7 0 0 0 8 0 C 4 A 2 0 0 0 0 ..... Frame of Effective Length 1 1/2 Byte Figure 55 Note: 1. Data is transmitted according to Q.921 2.8 and fully transparent. 2. A transmit descriptor with NO = 0 and FE = 1 is allowed, one with NO = 0 and FE = 0 is forbidden. 3. FNUM = 1 leads to 2 FLAGS after DATA 2. User's Manual 99 01.2000 PEB 20320 Functional Description TMR Receive Direction General Features 1. The starting and the ending flag (00 00H) is recognized. Interframe time-fill, both characters of the starting flag and the last character of the ending flag is extracted. 2. The number of bits within a frame is checked to be divisible by 8. 3. The number of bytes within a frame is checked to be smaller than MFL. More detailed description of the individual features 1. a. A frame is supposed to have started after a sequence of 16 zeros a `1'-bit is recognized. The frame is supposed to have this `1'-bit as first bit. b. A frame is supposed to have stopped if - either a sequence of 16 `zeros' and a `one' is found in the data stream after the frame has started - or a sequence of 16 zeros is found octet synchronous (i.e. the first bit of the sequence 00 00H is the 8m + 1st bit since the starting `1'-bit of 1.a. for an integer m). In both cases the eighth bit of the sequence 00 00H is supposed to be the last bit of the frame. 2. The check is reported in the NOB bit in the last receive descriptor of the frame. NOB = 1 the bit length of the frame was not divisible by 8. NOB = 0 the bit length of the frame was divisible by 8. If NOB = 1 the last byte of the last access to a receive data section of the frame may contain erroneous bits and shouldn't be evaluated. This does not affect the reception of frames with n + 1/2 octets 3. The check is reported in the LFD bit in the last receive descriptor of the frame. LFD = 1 the number of bytes was greater than MFL. LFD = 0 the number of bytes was smaller or equal to MFL. MFL + 1st one are transferred to the shared memory. The bytes of the last access to the receive data section of the frame may contain erroneous bits and shouldn't be evaluated. LFD is always accompanied by NOB. User's Manual 100 01.2000 PEB 20320 Functional Description Options There are no options in receive direction for this mode. Interrupts The possible interrupts for the mode in receive direction are identical to those of TMB. Example: TMR channel with INV = 0 (no inversion) CRC = 1 (required) TRV = 00 FA = 0 MODE = 01 (TMR) IFTF = 0 (required) MFL = 7 Motorola interface Channel No. 15 User's Manual 101 01.2000 PEB 20320 Functional Description (start) FLAG .... 00000000 DATA 1 1 00000000 10111001 10000000 octet synchronous (end) FLAG 2 00000000 octet synchronous FLAG DATA 2 00000000 11001011 0000 00000000 00000000 (start) FLAG non octet synchronous FLAG DATA 3 10000000 00000000 10111100 11110101 11000000 3 0000 11110001 11011111 01011001 01101010 00000000 DATA Ignored up to next Framestart octet synchronous (end) FLAG 4 DATA 4 11110011 11110111 11011101 11011011 11111111 00000000 DATA 5 00000000 Generate FI, HI-Int. 88003035 Generate FI-Int. 88001035 2 nd Desc 31 0 3 rd Desc 31 0 00040000 C0030000 200C0000 C0020000 00080000 C0060800 5 31 0 DATA 2 D3 00 XX XX 31 0 9D 01 00 XX 01111010 00000000 00000000 Generate FI, ERR-Int. 88001235 1 st Desc 31 0 DATA 1 11011101 NOB 31 0 01 00 3D AF 03 XX XX XX Last Byte of a NOB Frame should be Ignored DATA 3 Generate FI, HI, ERR-Int. 88003235 Generate HI-Int. 88002035 Generate FI-Int. 88001035 4 th Desc 31 0 5 th Desc 6 31 0 6 th Desc 31 0 20080000 40080000 20040000 C0000C00 00080000 C0030000 31 0 DATA 4 8F FB 9A 56 31 0 DATA 5 BB 5E 00 XX LFD, NOB Last Access of a LFD Frame should be Ignored ITD04565 Figure 56 User's Manual 102 01.2000 PEB 20320 Functional Description 1. After receive initialization is detected all data are ignored until a starting sequence (16 `zeros', `one') is detected. 2. The octet synchronous (end) flag of one frame can be part of the (start) flag of the next frame. Note, that the first 00H character of the end flag is stored in the receive data section as ordinary data and is included in BNO. Between DATA 2 and DATA 3 the start and end flag are identical (shared flags supported). 3. Here the start sequence is detected non-octet synchronously within a frame. Therefore the frame belonging to DATA 3 is supposed to have ended non-octet synchronously (NOB set in the 3rd descriptor). 4. After MFL + 1 data bytes the further data are ignored and are neither stored in the RB nor reported to the shared memory. 5. Data are formatted according to 2.8 of CCITT Q.921. 6. If a receive descriptor is full (4th descriptor) the MUNICH32 branches to the next receive descriptor (5th descriptor) even if no further data are to be given to the shared memory. For INV = 1 (channel inversion) all bits of the data stream (including DATA, FLAG) are interpreted inversely e.g. 16 `ones', `zero' is interpreted as starting sequence then. For Intel interface the only difference is in the receive data sections. They would be of 1st Desc 31 0 XX 00 01 9D of 2nd Desc 31 0 XX XX 00 D3 of 3rd Desc 31 0 AF 3D 00 01 XX XX XX 03 of 4th Desc 31 0 56 9A FB 8F of 6 th Desc 31 0 XX 00 5E BB ITD05035 Figure 57 User's Manual 103 01.2000 PEB 20320 Functional Description TMA Transmit Direction General Features In the transmit direction - a slot-synchronous transparent data transmission - a high impedance overwrite for the masked bits in the slot - a programmable number of programmable fill characters between data (also slot synchronous) is generated automatically. Options The different options for this mode are - The value of the fill-character can be programmed for FA = 1 in the channel specification. The fill-character (TC) is then programmed in the TFLAG. For FA = 0 the fill character is FFH and TFLAG has to be set to 00H. If subchanneling is chosen (not all fill/mask bits of the channel are `1') FA must be set to `0'. - The number of inter-data time-fill characters as shown in Figure 33 by choosing FNUM = 0, 1, 2 we have FNUM = 0 FNUM = 1 FNUM = 2 ... DATA 1, TC, DATA 2 ... ... DATA 1, TC, TC, DATA 2 ... ... DATA 1, TC, TC, TC, DATA 2 ... Interrupts The possible interrupts for this mode in transmit direction are identical to those of HDLC. User's Manual 104 01.2000 PEB 20320 Functional Description Example 1: (no subchanneling by fill/mask bits) TMA channel with TFLAG = B2H INV = 0 (no data inversion) CRC = 0 (required) TRV = 00 (required) FA = 1 (flag filtering) MODE = 00 (TMA) IFTF = 0 (required) All fill-mask bits are `1' for this channel (no high impedance overwrite) Intel interface Channel no. D Time-Slot Boundaries Bit No 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 DATA 1 ..... 1 DATA 2 TC 2 DATA 3 2 TCs DATA 4 D 5 8 B 6 C 4 8 0 0 B 2 4 F B 2 B 2 8 B B 4 4 C ..... Generate HI-, FI-Interrupt 8800300D Generate HI-Interrupt 8800200D 1 st Desc 31 0 2 nd Desc 31 0 3 rd Desc 31 0 4 th Desc 31 0 20020000 A0030000 80010001 00030000 0 0 0 31 0 DATA 1 XX XX D1 AB 31 0 DATA 2 XX 00 12 36 For INV=1 DATA and TC would be Inverted 31 0 DATA 3 XX XX XX F2 0 31 0 DATA 4 XX 32 2D D1 ITD04564 Figure 58 Note: 1. Data are formatted according to 2.8 of Q.921. The TC is transmitted MSB (bit 15) first though!!! 2. FNUM = 0 in the second descriptor leads to the insertion of the TC after DATA 2, FNUM = 1 in the third descriptor to the insertion of 2 TCs. User's Manual 105 01.2000 PEB 20320 Functional Description For INV = 1 the data stream would be inverted completely DATA 1 DATA 2 ... 2A 74 TC DATA 3 2 TCs 93 B7 FF 4D B0 DATA 4 4D 4D 74 4B B3 ... Figure 59 For FA = 0 TFLAG has to be programmed to 00H and the data stream would be DATA 1 DATA 2 TC DATA 3 2 TCs D5 8B 6C 48 00 FF 4F DATA 4 FF FF 8B B4 4C Figure 60 For Motorola mode the data sections leading to the same data stream would have been of 1st Desc 31 0 AB D1 XX XX of 2nd Desc 31 0 36 12 00 XX of 3 rd Desc 31 0 F2 XX XX XX of 4 th Desc 31 0 D1 2D 32 XX ITD05036 Figure 61 User's Manual 106 01.2000 PEB 20320 Functional Description Example 2: (subchanneling by fill/mask bits) TMA channel with TFLAG = 00H (required for this case) INV = 0 (no data inversion) CRC = 0 (required) TRV = 00 (required) FA = 0 (required for subchanneling) MODE = 00 (TMA) IFTF = 0 (required) Intel interface Channel no. D Generate HI-Interrupt 8800200D Generate HI-Interrupt 8800200D 1 st Desc 31 0 2 nd Desc 31 0 3 rd Desc 31 0 4 th Desc 31 0 20020000 A0030000 80010001 00030000 0 0 0 31 0 DATA 1 XX XX D1 AB 31 0 DATA 2 XX 00 12 36 31 0 DATA 3 XX XX XX F2 0 31 0 DATA 4 XX 32 2D D1 ITD04563 Figure 62 User's Manual 107 01.2000 User's Manual 0 12345670 12345670 12345670 12345670 12345670 1234567 108 Slot Boundaries 0 12345670 12345670 12345670 12345670 12345670 1234567 ITD04561 TC (FF) 2 TCs (FF FF) DATA 4 (8B B4 4C) ITD04562 0 10Z 11111Z 11111Z 111Z 1111Z000 1Z 11ZZ 110Z00Z 100 1100 External Data DATA 3 (4F) 0 100 111111111111111111111000 10 1110 110 1000 100 1100 Internal Data 1110 111110 111110 1110 11110 11110 1100 1110 110 1111111 Fill/Mask High Imp. Overwrite Bit No DATA 2 (6C 48 00) Z 1ZZ0 1Z 11000 10 11ZZZZZZZZ0 1Z0 10Z0000Z0Z00ZZ 111111 External Data (TDATA) DATA 1 (D5 8B) 110 10 10 11000 10 110 110 11000 100 100000000000 11111111 Internal Data 0 100 110 11111111100000000 110 1110 11110 10 1100 111111 Fill/Mask High Imp. Overwrite Bit No Slot Boundaries PEB 20320 Functional Description Figure 63 Note: Example 2 uses the same descriptors as example 1. Those bits in the data stream that are at places where fill/mask is `zero' are overwritten by `Z' i.e. high impedance. In all other protocols bits of the data stream are not overwritten by fill/mask zero bits. Instead the whole data stream is sent at fill/mask one bits for all other protocols. 01.2000 PEB 20320 Functional Description TMA Receive Direction General Features In the receive direction - a slot synchronous transparent data reception - a `1' overwrite for masked bits in the slot - for FA = `1' a slot synchronous programmable flag extraction is performed automatically. Options The different options for this mode are: - the programmable character TC to be extracted for FA = `1' is TFLAG. For FA = `0' nothing is extracted. If subchanneling is chosen (not all fill/mask bits of the channel are `1') FA must be set to `0'. Interrupts The possible interrupts for the mode in receive direction are: HI: issued if the HI bit is detected in the receive descriptor (not maskable). ERR: issued if a fast receive abort channel command was issued. (maskable by RE in the channel spec.) FO: issued if data could only partially stored due to internal buffer overflow of RB. (maskable by RE in the channel spec.) Example 1: (no subchanneling) TMA channel with TFLAG = D7 INV = 0 (no channel inversion) CRC = 0 (required) TRV = 00 (required) FA = 1 MODE = 00 (TMA) IFTF = 0 Motorola interface Channel No. E User's Manual 109 01.2000 PEB 20320 Functional Description Slot Boundaries 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0 D6 D7 AF BD 0 0 D7 D7 2 8 6 3 D7 7 D 7 8 Octet Synchr. TC 2 Octet Synchr. TCs Octet Not Synchr. Octet TC Synchr. TC not Filtered Generate HI-Interrupt 8800202E 31 31 0 00040000 40040000 0 20040000 40040000 31 0 6B F5 BD 00 31 0 14 C6 BE 1E ITD04560 Figure 64 Note: The FE bit is never set in a receive descriptor. The data are formatted according to 2.8 Q.921. For FA = 0 (and therefore TFLAG = 00H) The descriptor would be Generate HI-Interrupt 8800202E 31 0 31 00040000 40040000 0 31 20040000 40040000 31 0 6B EB F5 BD 0 00040000 40040000 31 0 00 EB EB 14 31 0 C6 EB BE 1E ITD04559 Figure 65 User's Manual 110 01.2000 PEB 20320 Functional Description For INV = 1 the receiver filters the inverse of the TFLAG as TC out of the data stream and inverts the data (only the octet synchronous 28H would be filtered). For Intel interface the data sections would be 00 BD F5 6B for the first descriptor and 1E BE C6 14 for the second. Example 2: (with subchanneling) TMA channel with TFLAG = 00H (required because of subchanneling) INV = 0 (no channel inversion) CRC = 0 (required) TRV = 00 (required) FA = 0 (required because of subchanneling) MODE = 00 (TMA) IFTF = 0 Motorola interface Channel No. E User's Manual 111 01.2000 PEB 20320 Functional Description Slot Boundaries Fill/Mask "one" Overwrite 111111110 100 11000 10 11000 10 11110 1 External Data (RDATA) 000000000 1100 110 1110 100 100 10 100 1 Internal Data 00000000 11110 1111110 11110 110 10 11 For INV=1 1111111110 1110 1110 110 111110 10 110 31 0 00040000 40040000 31 0 00 EF F7 D6 ITD04558 Figure 66 User's Manual 112 01.2000 PEB 20320 Functional Description V.110/X.30 Transmit Direction General Features In transmit direction - the synchronization pattern for V.110/X.30 frame as shown in Table 1. - the framing for the different data rates with programmable E-, S-, X-bits - sending `0' before all frames is performed automatically. Table 1 Synchronization Pattern for V.110/X.30-Frames Octet No. 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 The E-, S-, X-bits are fed into the data stream by special transmit descriptor (as shown in Figure 30), they can only change from one 10-octet frame to the next, not within a 10octet frame. The data from the data sections are supposed to come in the form: 31 0 1 1 B6 B5 B4 B3 B2 B1 1 1 B12 B11 B10 B9 B8 B7 1 1 B18 B17 B16 B15 B14 B13 1 1 B24 B23 B22 B21 B20 B19 (for Motorola mode), 31 0 1 1 B24 B23 B22 B21 B20 B19 1 1 B18 B17 B16 B15 B14 B13 1 1 B12 B11 B10 B9 B8 B7 1 1 B6 B5 B4 B3 B2 B1 (for Intel mode). where for 600 bit/s e.g. B1 to B6 belong to the first 10-octet frame, B7 to B12 belong to the second 10-octet frame, etc. User's Manual 113 01.2000 PEB 20320 Functional Description Options The different options for this mode are: - the framing pattern, as shown in Table 2 to Table 5, is programmed by the bits TRV. Interrupts HI: issued if the HI bit is detected in the transmit descriptor (not maskable) ERR: if one of the following transmit errors has occurred - the last descriptor had FE = 1 (leads to an abort of the transmit data, see Figure 31) - the last descriptor had H = 1 (see Figure 29) - the last descriptor had NO = 0 (maskable by TE in the channel spec.) FO: one of the following transmit errors has occurred - a BERR = `0' was detected during a read access to a transmit data section for this channel - the MUNICH32 was unable to access the shared memory in time either for new data to be sent or for a new descriptor. (maskable by TE in the channel spec.) User's Manual 114 01.2000 PEB 20320 Functional Description Example X.30/V110 channel with CS = 0 (required) INV = 0 CRC = 0 TRV variable (all values shown in examples) FA = 0 (required) MODE = 10 (V.110/X.30) Intel interface Channel No. 1F Generate HI-Interrupt 8800201F 31 0 31 00028000 20030000 0 E, S, X 0 31 0 31 0 31 0 DATA 1 XX FA D6 C3 E, S, X 0 00030000 20018000 0 31 0 1 75 40 00 00 Generate HI-Interrupt 880201F 0 31 0 2 8A 80 00 00 31 0 DATA 2 XX D1 E2 C0 ITD05037 Figure 67 Note: The first transmit descriptor must have the V.110-bit set. User's Manual 115 01.2000 PEB 20320 Functional Description TRV = 00 0 1 1 1 1 1 1 1 1 1 0 1 1 1 0 0 0 0 0 0 0 1 1 1 0 1 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 1 1 1 0 1 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 0 1 0 1 0 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 0 0 1 1 0 0 0 1 0 0 0 0 1 1 1 0 0 1 0 0 0 1 1 1 0 0 1 1 0 0 0 1 1 1 1 0 1 1 0 0 0 1 1 1 1 0 1 0 0 0 0 1 1 1 1 0 1 0 0 0 0 1 0 1 0 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 0 0 1 0 1 1 1 1 1 0 0 1 1 0 0 1 1 1 1 0 0 1 1 0 1 1 1 1 1 0 0 1 0 0 1 1 1 1 1 0 0 1 0 0 1 1 1 1 1 0 0 1 0 1 0 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1 0 1 0 0 1 1 1 1 1 1 1 1 1 0 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 1 0 0 1 1 0 1 0 0 0 1 0 0 1 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 1 0 1 0 1 0 1 1 0 1 0 0 1 1 1 1 1 1 1 1 1 0 1 1 0 0 1 0 0 1 0 0 1 1 0 0 0 0 0 1 0 0 1 0 0 0 1 0 1 1 0 0 1 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 1 0 0 0 1 0 1 0 1 1 0 1 0 User's Manual SA X SB 1 E1E2E3E4E5E6E7 D6 = 11 0 1 0 1 1 0 B6B5B4B3B2B1 FA = 11 1 1 1 0 1 0 B6B5B4B3B2B1 Change of E-, S-, X-bits 116 01.2000 PEB 20320 Functional Description TRV = 01 0 1 1 1 1 1 1 1 1 1 0 1 1 0 0 0 0 1 0 1 0 1 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 0 0 0 1 0 0 0 1 0 1 0 0 0 1 0 0 0 1 1 1 1 0 0 1 0 0 0 1 1 1 1 0 0 0 1 0 1 0 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 0 1 1 1 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 1 0 1 1 1 0 0 0 0 0 1 0 1 1 1 0 0 0 0 0 0 1 0 1 0 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 0 1 0 0 1 1 0 0 1 0 0 1 0 0 0 1 0 0 1 0 0 0 0 1 1 1 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 0 0 1 0 0 0 1 0 0 1 0 0 1 0 0 0 1 0 0 1 0 1 0 1 1 0 1 0 SA X SB 1 E1E2E3E4E5E6E7 FA (last byte of DATA 1) 11 1 1 1 0 1 0 B6B5B4B3B2B1 C0 (first byte of DATA 2) 11 0 0 0 0 0 0 B6B5B4B3B2B1 Change of E-, S-, X-bits E2 = 1 1 1 0 0 0 1 0 B6B5B4B3B2B1 D1 = 1 1 0 1 0 0 0 1 B6B5B4B3B2B1 TRV = 10 0 1 1 1 1 1 1 1 1 1 0 1 0 0 0 0 0 1 0 0 0 1 0 0 0 1 0 1 0 0 0 1 0 1 1 0 1 1 0 0 0 1 0 1 1 1 1 1 0 0 0 0 0 1 0 1 0 1 0 0 0 0 0 1 0 1 0 1 0 0 0 0 1 0 1 0 0 1 0 1 0 1 1 1 1 1 1 1 1 1 0 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 1 1 0 1 0 0 1 0 0 0 1 0 0 0 0 0 1 0 0 0 0 1 0 1 0 1 1 0 1 0 User's Manual SA X SB 1 E1E2E3E4E5E6E7 Change of E-, S-, X-bits E2 = 1 1 1 0 0 0 1 0 B6B5B4B3B2B1 D1 = 1 1 0 1 0 0 0 1 B6B5B4B3B2B1 117 01.2000 PEB 20320 Functional Description TRV = 11 0 1 1 1 1 1 1 1 1 1 0 1 0 0 0 0 0 1 0 1 1 1 0 1 1 0 0 0 1 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 1 0 1 0 1 0 0 0 1 0 1 1 0 0 0 1 0 1 0 0 1 0 1 Change of E-, S-, X-bits For INV = 1 (channel inversion) all bits are inverted. For Motorola mode the data sections would have to have the form to yield the same output data. 31 0 E, S, X 1 00 00 40 75 31 0 DATA 1 C3 86 FA XX 31 0 31 0 E, S, X 2 00 00 80 8A DATA 2 C0 E2 D1 XX XX XX 00 03 ITD05038 Figure 68 User's Manual 118 01.2000 PEB 20320 Functional Description V.110/X.30 Receive Direction General Features In receive direction - the starting sequence (00H followed by a `1'-bit) after initialization of loss of synchronism is detected. - the synchronization pattern is monitored, after 3 consecutive erroneous frames a loss of synchronism is detected. - a change of E-, S-, X-bits is monitored and reported by an interrupt. - the data bits are extracted and written into the data section. More detailed description of the individual features: 1. and 2. the receiver can be in one of 2 states: RESET Unsynchronous State 8 * "0" bit followed by a "1" bit 3 Consecutive Erroneous Frames (with a Frame Error) Synchronous State ITD05039 Figure 69 Data extraction and monitoring of a change of E-, S-, X-bits and synchronization pattern is only performed in synchronized state. In the asynchronous state the receiver waits for the synchronization patter. The `1'-bit is then interpreted as bit 1 of octet 2. 3. During the synchronized state a change of E, S, X-bits from one frame to the next and even within a frame (for SA, SB bits) is monitored. Only one interrupt per frame is reported even if SA e.g. changes 3 times within the frame. The E-, S-, X-bits reported in the interrupt are S9 for SB and S8 for SA and the second occurrence of X for X. 4. The bits written into the data section are marked by O in Table 2 to Table 4. As shown, bits repeated in the serial data are only strobed than at their last instance. User's Manual 119 01.2000 PEB 20320 Functional Description Table 2 Framing for Networks with 600-bit/s Data Rate Intermediate Rate = 8 Kbit/s, i.e. Subchannelling with Only 1 Fill/Mask Bit Set Octet No. 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 0 1 1 1 1 1 1 1 1 1 0 B1 B1 B2 B3 E1 B4 B4 B5 B6 0 B1 B1 B2 B3 E2 B4 B4 B5 B6 0 B1 B2 B2 B3 E3 B4 B5 B5 B6 0 B1 B2 B2 B3 E4 B4 B5 B5 B6 0 B1 B2 B3 B3 E5 B4 B5 B6 B6 0 B1 B2 B3 B3 E6 B4 B5 B6 B6 0 S1 X S3 S4 E7 S6 X S8 S9 Table 3 Framing for Networks with 1200-bit/s Data Rate Intermediate Rate = 8 Kbit/s, i.e. Subchannelling with Only 1 Fill/Mask Bit Set Octet No. 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 0 1 1 1 1 1 1 1 1 1 0 B1 B2 B4 B5 E1 B7 B8 B10 B11 0 B1 B2 B4 B5 E2 B7 B8 B10 B11 0 B1 B3 B4 B6 E3 B7 B9 B10 B12 0 B1 B3 B4 B6 E4 B7 B9 B10 B12 0 B2 B3 B5 B6 E5 B8 B9 B11 B12 0 B2 B3 B5 B6 E6 B8 B9 B11 B12 0 S1 X S3 S4 E7 S6 X S8 S9 User's Manual 120 01.2000 PEB 20320 Functional Description Table 4 Framing for Networks with 2400-bit/s Data Rate Intermediate Rate = 8 Kbit/s, i.e. Subchannelling with Only 1 Fill/Mask Bit Set Octet No. 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 0 1 1 1 1 1 1 1 1 1 0 B1 B4 B7 B10 E1 B13 B16 B19 B22 0 B1 B4 B7 B10 E2 B13 B16 B19 B22 0 B2 B5 B8 B11 E3 B14 B17 B20 B23 0 B2 B5 B8 B11 E4 B14 B17 B20 B23 0 B3 B6 B9 B12 E5 B15 B18 B21 B24 0 B3 B6 B9 B12 E6 B15 B18 B21 B24 0 S1 X S3 S4 E7 S6 X S8 S9 Table 5 Framing for Networks with 4800-, 9600-, 19200-, 38400-bit/s Data Rate Intermediate Rate = 8, 16, 32, 64 Kbit/s, i.e. Subchannelling with 1, 2, 4, 8 Fill/Mask Bit Set Octet No. 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 0 1 1 1 1 1 1 1 1 1 0 B1 B7 B13 B19 E1 B25 B31 B37 B43 0 B2 B8 B14 B20 E2 B25 B32 B36 B44 0 B3 B9 B15 B21 E3 B27 B33 B39 B45 0 B4 B10 B16 B22 E4 B29 B35 B41 B47 0 B5 B11 B17 B23 E5 B29 B35 B41 B47 0 B6 B12 B18 B24 E6 B30 B36 B42 B48 0 S1 X S3 S4 E7 S6 X S8 S9 They are grouped together in the form: 31 0 1 1 B6 B5 B4 B3 B2 B1 1 1 B12 B11 B10 B9 B8 B7 1 1 B18 B17 B16 B15 B14 B13 1 1 B24 B23 B22 B21 B20 B19 (for Motorola mode) 31 0 1 1 B24 B23 B22 B21 B20 B19 1 1 B18 B17 B16 B15 B14 B13 1 1 B12 B11 B10 B9 B8 B7 1 1 B6 B5 B4 B3 B2 B1 (for Intel mode) where for the 600 bit/s e.g. B1 to B6 belong to the first 10-octet frame, B7 to B12 belong to the second 10-octet frame etc. User's Manual 121 01.2000 PEB 20320 Functional Description Options The different options for this mode are the framing pattern as shown in Table 2 to Table 5 is programmed by the bits TRV. Interrupts The possible interrupts for this mode are FRC: issued if the receiver has detected a change of S-, X-, E-bits; the value of the bits E7, ..., E1, S8 for SA and S9 for SB and the second occurrence of X within the 10octet frame is reported within the same interrupt. (maskable by CH in the channel specification HI: issued if the HI bit is detected in the transmit descriptor (not maskable). ERR: issued if one of the following receive errors has occurred: - a fast receive abort channel command was issued (this leads to a setting of the RA bit in the status byte) - data could only partly be stored due to internal buffer overflow of RB - 3 consecutive frames had an error in the synchronization pattern (loss of synchronism) - the HOLD bit in the receive descriptor was detected (this leads to a setting of the RA bit in status in the receive descriptor). (maskable by RE in the channel specification) FO: issued if due to inaccessibility of the internal buffer (RB) one or more changes of E-, S-, X-bits and/or loss of synchronism information have been lost. (maskable by RE in the channel specification) Example V.110/X.30 channel with CS = 0 (required) INV = 0 CRC = 0 TRV = 00 (600 bit/s) FA = 0 MODE = 10 (V.110/X.30) Motorola interface Channel No. D User's Manual 122 01.2000 PEB 20320 Functional Description ... 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 1 1 1 1 1 0 1 0 0 1 1 1 1 1 1 1 0 0 0 0 1 0 0 1 1 1 1 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1 0 1 0 0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 1 0 0 0 1 0 1 1 1 0 0 0 0 0 1 0 1 1 1 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 1 0 1 1 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 1 0 0 0 1 0 0 0 1 1 1 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 1 0 0 0 1 0 1 1 1 1 1 0 0 0 1 0 1 1 1 1 1 0 0 1 1 0 0 1 1 1 1 0 0 1 1 0 1 1 1 1 1 0 0 1 0 0 0 1 1 1 1 0 0 1 0 0 0 1 1 1 1 0 0 1 1 0 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 1 1 1 0 MUNICH32 waits for synchronization after reset 1 1 1 0 1 0 0 1 E9 H B6 B5 B4 B3 B2 B1 Reported as X Reported as SA Reported as SB Error in synchronization pattern 1 1 0 0 1 0 1 0 CAH B6 B5 B4 B3 B2 B1 No change of E, S, X Bits Change of E, S, X Bits; but SA is still reported as '1' 1 1 1 1 1 0 1 0 FA H B6 B5 B4 B3 B2 B1 Reported as SA Error in synchronization pattern 1 1 0 1 0 0 1 0 D2 H B6 B5 B4 B3 B2 B1 No change of E, S, X Bits Error in synchronization pattern ITS08219 Figure 70a User's Manual 123 01.2000 PEB 20320 Functional Description 0 1 1 1 1 1 1 1 1 0 0 0 1 0 1 1 0 1 0 1 0 0 1 0 1 1 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 1 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 FF H 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 FF H Change of E, S, X Bits 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 C0 H EDH No change of E, S, X Bits Error in synchronization pattern Change of E, S, X Bits No error in synchronization pattern Change of E, S, X Bits Error in synchronization pattern ITS08220 Figure 70b User's Manual 124 01.2000 PEB 20320 Functional Description 8FFF002D 8F57002D 8C00002D 8800202D 8E5B002D 8E5B002D 8800022D st 1 Desc 31 2 31 0 00080000 40042000 Loss of Synch. nd Desc 0 20040000 40040000 31 0 E9 CA FA D2 31 0 ED FF FF C0 ITD05040 Figure 71 For Intel mode the data sections have the form: of 1st Desc 31 0 D2 FA CA E9 of 2 nd Desc 31 0 C0 FF FF ED ITD05041 Figure 72 User's Manual 125 01.2000 PEB 20320 Functional Description 2.5 Boundary Scan Unit In MUNICH32 a Test Access Port (TAP) controller is implemented. The essential part of the TAP is a finite state machine (16 states) controlling the different operational modes of the boundary scan. Both, TAP controller and boundary scan, meet the requirements given by the JTAG standard: IEEE Std. 1149.1. Figure 73 gives an overview. Test Access Port Pins JTEST0 (TCK) Clock Generation 1 2 CLOCK Reset JTEST1 (TMS) Test Control BS Data IN TAP Controller Control Bus JTEST2 (TDI) Data IN JTEST3 (TDO) -Finite State Machine -Instruction Register (3 bits) -Test Signal Generator 6 Boundary Scan (n Bits) Power ON Reset Identification Scan (32 Bits) CLOCK ID Data OUT Enable SS Data OUT n Data OUT ITB03509 Figure 73 Block Diagram of Test Access Port and Boundary Scan Test handling is performed via the pins JTEST0 (TCK), JTEST1 (TMS), JTEST2 (TDI) and JTEST3 (TDO). Test data at JTEST2 (TDI) are loaded with a 4-MHz clock signal connected to JTEST0 (TCK). `1' or `0' on JTEST1 (TMS) causes a transition from one controller state to an other; constant `1' on JTEST1 (TMS) leads to normal operation of the chip. If no boundary scan testing is planned JTEST1 (TMS) and JTEST2 (TDI) do not need to be connected since pull-up transistors ensure high input levels in this case. Nevertheless it would be a good practice to put the unused inputs to defined levels. In this case, if the JTAG is not used: JTEST1 = JTEST0 = `1'. After switching on the device (VDD = 0 to 5 V) a power-on reset is generated which forces the TAP controller into test logic reset state. User's Manual 126 01.2000 PEB 20320 Functional Description Table 6 Boundary Scan Sequence in PEB 20320 JTEST2 (TDI) Pin No. Pin I/O Number of Boundary Scan Cells Constant Value 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Reset SCLK TEST AR TDATA TSP TCLK I/M B16 Ready/DSACK BERR HLDA/BG HLDAO/BGO BGACK HOLD/BR ADS/AS DS WR/RW BE3 BE2 D0 BE1 D1 BE0 D2 A2 D3 A3 D4 A4 D5 A5 D6 A6 D7 I I I I O I I I I I I I O I/O I/O O O O O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O 1 1 1 1 2 1 1 1 1 1 1 1 2 3 3 2 2 2 2 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 0 1 1 0 00 0 0 0 0 0 0 0 00 001 010 00 01 00 00 01 100 00 000 00 000 00 000 00 000 00 000 00 000 00 000 User's Manual 127 01.2000 PEB 20320 Functional Description Table 6 Boundary Scan Sequence in PEB 20320 (cont'd) JTEST2 (TDI) 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 Pin I/O Number of Boundary Scan Cells Constant Value A7 D8 A8 D9 A9 D10 A10 D11 A11 D12 A12 D13 A13 D14 A14 D15 A15 D16 A16 D17 A17 D18 A18 D19 A19 D20 A20 D21 A21 D22 A22 D23 A23 D24 A24 O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 User's Manual 128 01.2000 PEB 20320 Functional Description Table 6 Boundary Scan Sequence in PEB 20320 (cont'd) JTEST2 (TDI) 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 Pin I/O Number of Boundary Scan Cells Constant Value D25 A25 D26 A26 D27 A27 D28 A28/DP0 D29 A29/DP1 D30 A30/DP2 D31 A31/DP3 INT/INT RCLK RSP RDATA CI0 CI1 CI2 CI3 CI4 I/O O I/O O I/O O I/O I/O I/O I/O I/O I/O I/O I/O O I I I I I I I I 3 2 3 2 3 2 3 3 3 3 3 3 3 3 2 1 1 1 1 1 1 1 1 000 00 000 00 000 00 000 000 000 000 000 000 000 000 00 0 0 0 0 0 0 0 0 JTEST3 (TDO) An input pin (I) uses one boundary scan cell (data in), an output pin (O) uses two cells (data out, enable) and an I/O-pin (IO) uses three cells (data in, data out, enable). Therefore the boundary scan of the MUNICH32 contains a total of n = 205 scan cells. The right column of Table 6 gives the initialization values of the cells. The desired test mode is selected by serially loading a 3-bit instruction code into the instruction register via JTEST2 (TDI) (LSB first); see Table 3. User's Manual 129 01.2000 PEB 20320 Functional Description Table 7 Boundary Scan Test Modes Instruction (Bit 2 ... 0) Test Mode 000 001 010 011 111 others EXTEST (external testing) INTEST (internal testing) SAMPLE/PRELOAD (snap-shot testing) IDCODE (reading ID code) BYPASS (bypass operation) handled like BYPASS EXTEST is used to examine the interconnection of the devices on the board. In this test mode at first all input pins capture the current level on the corresponding external interconnection line, whereas all output pins are held at constant values (`0' or `1', according to Table 6). Then the content of the boundary scan is shifted to JTEST3 (TDO). At the same time the next scan vector is loaded from JTEST2 (TDI). Subsequently all output pins are updated according to the new boundary scan contents and all input pins again capture the current external level afterwards, and so on. INTEST supports internal testing of the chip, i.e. the output pins capture the current level on the corresponding internal line whereas all input pins are held on constant values (`0' or `1', according to Table 6). The resulting boundary scan vector is shifted to JTEST3 (TDO). The next test vector is serially loaded via JTEST2 (TDI). Then all input pins are updated for the following test cycle. Note: In capture IR-state the code `001' is automatically loaded into the instruction register, i.e. if INTEST is wanted the shift IR-state does not need to be passed. SAMPLE/PRELOAD is a test mode which provides a snap-shot of pin levels during normal operation. IDCODE: A 32-bit identification register is serially read out via JTEST3 (TDO). It contains the version number (4 bits), the device code (16 bits) and the manufacturer code (11 bits). The LSB is fixed to `1'. JTEST2 (TDI) 0110 0000 0000 0000 0101 0000 1000 001 1 IDCODE for old versions: JTEST3 (TDO) 0001 for version 2.1 0010 for version 2.2 0100 for version 3.2 Note: As in test logic reset state the code `011' is automatically loaded into the instruction register the ID code can easily be read out in shift DR state which is reached by JTEST1 (TMS) = 0, 1, 0, 0. BYPASS: A bit entering JTEST2 (TDI) is shifted to JTEST3 (TDO) after one JTEST0 (TCK) clock cycle. User's Manual 130 01.2000 PEB 20320 Operational Description 3 Operational Description 3.1 Reset State Upon reset MUNICH32 is set to its initial state. The active high system reset clears the internal logic and causes MUNICH32 to tristate all output lines. Channel processing is deactivated. After reset all buffers are empty and no buffer size of TB is allocated to the channels. The DMA controller state is set to the hold condition for all link lists. The descriptor and data pointers remain at a random value. The bits RO and TO are set to `1' and RA and TA are set to `0' for all logical channels by reset. All time slots are connected to the logical channel 0 and the following configuration is set: Action Specification LOC = LOOP = LOOPI = 0 PCM = T1/DS1 x 24-channel 1.536 Mbit/s (000) MFL = 0 Time Slot Assignment fill/mask = 00H, i.e. all bits masked/set to `1' RTI, TTI = 0 channel number = 00H Channel Specification MODE = 00, i.e. TMA FA = 0 IFTF = 0 CRC = 0 INV = 0 TRV = 00, RO = 1 RA = 0 TO = 1 TA = 0 TH = 0 User's Manual 131 01.2000 PEB 20320 Operational Description Transmit Descriptor FNUM = 00H, i.e. shared flags in HDLC, only eight zero bits between sent frames for TMB. The E-, S-, X-bits are all set to zero internally by the reset. The receiver is set into the ITF/IDLE state for all channels, i.e. it assumes that on the line there are `1's as interframe time-fill for HDLC. 3.2 Initialization Procedure After reset MUNICH32 remains in the initial state until the microprocessor generates an action request. In the action specification the initialization sequence is defined. The sequence can be split up into individual procedures of each channel or in one single procedure to initialize all channels at the same time. For all procedures the time slot assignment and the selected channel specifications are loaded into the CSR-RAM. To prevent malfunction the initialization of the link lists and the allocation of the buffer size to the channels has to be specified before the transmission can be started. The interrupt queue must be established as well. MUNICH32 assumes that time slot 0 starts on the receive and transmit lines. They can be resynchronized by 2 rising edges of TSP and RSP respectively. The first rising edge of TSP/RSP should not take place within the first 1000 SCLK clock cycles after deassertion of the reset pin. Before this resynchronization the host should neither remove RO = 1, TO = 1 nor set LOOP or LOOPI to `1' for any logical channel. During this time any incoming data is ignored, the transmit data line tristated. For each action service the device first reads the control start address in the control and configuration section which is located under a fixed address determined by the input signals (CI(4:0)). The values of CI(4:0) can be changed during operation. The values are used after the next falling edge of AR. CI4 is the polarity of A31 ... A22 CI3 is the polarity of A21 ... A16 CI2 is the polarity of A15 ... A4 CI1 is the polarity of A3 CI0 is the polarity of A2 A0, A1 = 0 for example CI(4:0) = 10101 ADDRESS = 1111.1111.1100.0000.1111.1111.1111.0100 User's Manual 132 01.2000 PEB 20320 Operational Description 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 CI4 CI3 8 7 CI2 6 5 4 3 2 CI1 CI0 1 0 0 0 Figure 74 CI4 CI3 CI2 CI1 CI0 Loc. of Ctrl. Start Addr. CI4 CI3 CI2 CI1 CI0 Loc. of Ctrl. Start Addr. 0 0 0 0 0 0000 0000 1 0 0 0 0 FFC0 0000 0 0 0 0 1 0000 0004 1 0 0 0 1 FFC0 0004 0 0 0 1 0 0000 0008 1 0 0 1 0 FFC0 0008 0 0 0 1 1 0000 000C 1 0 0 1 1 FFC0 000C 0 0 1 0 0 0000 FFF0 1 0 1 0 0 FFC0 FFF0 0 0 1 0 1 0000 FFF4 1 0 1 0 1 FFC0 FFF4 0 0 1 1 0 0000 FFF8 1 0 1 1 0 FFC0 FFF8 0 0 1 1 1 0000 FFFC 1 0 1 1 1 FFC0 FFFC 0 1 0 0 0 003F 0000 1 1 0 0 0 FFFF 0000 0 1 0 0 1 003F 0004 1 1 0 0 1 FFFF 0004 0 1 0 1 0 003F 0008 1 1 0 1 0 FFFF 0008 0 1 0 1 1 003F 000C 1 1 0 1 1 FFFF 000C 0 1 1 0 0 003F FFF0 1 1 1 0 0 FFFF FFF0 0 1 1 0 1 003F FFF4 1 1 1 0 1 FFFF FFF4 0 1 1 1 0 003F FFF8 1 1 1 1 0 FFFF FFF8 0 1 1 1 1 003F FFFC 1 1 1 1 1 FFFF FFFC Figure 75 CI-Pin Decoding User's Manual 133 01.2000 PEB 20320 Detailed Register Description 4 Detailed Register Description 4.1 Organization of the Shared Memory Because the MUNICH32 reads only long words, all addresses of the link lists, interrupt queue and the CCS must be a multiple of four; i.e. the two least significant bits of the address must be `00'. Figure 76 depicts the organization of the shared memory for one MUNICH32. User's Manual 134 01.2000 PEB 20320 Detailed Register Description CCBA Control Start Address Receive DATA Channel 0 Action Specification Interrupt Circular Queue Interrupt Queue Specification Time Slot 0 Assignment Receive Descriptor Channel 0 Time Slot 31 Assignment Transmit DATA Channel 0 Receive Descriptor Channel 0 Channel 0 Specification Transmit Descriptor Channel 0 Transmit Descriptor Channel 0 Channel 31 Specification Last 8 Blocks not used in T1/DS1 Mode Current Receive Descriptor Address Channel 0 Current Receive Descriptor Address Channel 31 Current Transmit Descriptor Address Channel 0 Current Transmit Descriptor Address Channel 31 Control and Configuration Section ITD03508 Figure 76 Organization of the Shared Memory User's Manual 135 01.2000 PEB 20320 Detailed Register Description 4.2 Control and Configuration Section Table 8 Buffer Size of the Control and Configuration Section Control and Configuration Section Number of Long Words Action specification 1 Interrupt queue specification 2 Time slot assignment 32 Channel specification 128 Current descriptor address 64 4.2.1 Action Specification (Read Once After Each Action Request Pulse) All actions are selected by setting the corresponding bits to `1'. 31 30 29 28 27 26 25 24 23 22 20 19 18 17 16 4 3 2 1 0 IM RES LOC LOOP LOOPI IA 0 0 PCM 15 14 IN IC0 21 MFL 13 0 12 11 10 9 Channel Number 8 7 6 5 PCM: These three bits determine the PCM highway format. 000: T1/DS1 24-channel 1.536 Mbit/s 100: T1/DS1 24-channel 1.544 Mbit/s 101: CEPT 32-channel 110: 4.096-Mbit/s PCM format and even numbered time slots 111: 4.096-Mbit/s PCM format and odd numbered time slots MFL: Maximum Frame Length (up to 8191 bytes); MUNICH32 monitors the frame length of the incoming HDLC, TMB or TMR frames. If the maximum frame length is exceeded an interrupt is generated and the current frame aborted. The length check is active in all modes except transparent mode A and V.110/X.30. Therefore in all other modes one has to write a reasonable value to MFL after reset. MFL is the same for all logical channels. User's Manual 136 01.2000 PEB 20320 Detailed Register Description IN: Initialization procedure; setting this bit to one causes MUNICH32 to fetch all the time slot assignments and the channel specification of the selected channel (channel number). To avoid collision all time slots being reinitialized should be in a deactivated mode, i.e. the receive and transmit channels must be switched off. ICO: Initialize Channel Only; only the channel specification of the selected channel (channel number) is read and reconfigured. IM: Interrupt Mask; MUNICH32 suppresses the interrupt normally generated in order to acknowledge the action request. RES: RESET; a single initialization procedure is performed. The time slot assignment and all channel specifications are written into the CSR. All time slots are reinitialized. Note 1: The bits IN, ICO, RES are mutually exclusive within one action specification. They establish different ways of initializing, configuring and reconfiguring the channels and time slots of the MUNICH32. For test purposes four different loops can be switched at the serial interface with aid of LOC, LOOP, LOOPI according to the following table LOC 0 1 0 1 0 1 0 1 LOOP 0 0 0 0 1 1 1 1 LOOPI 0 0 1 1 0 0 1 1 Interpretation no loop not allowed complete internal loop channelwise internal loop complete external loop channelwise external loop not allowed not allowed The loops have the following functions: - Complete external loop The serial data input is physically mirrored back to the serial data output. The time and strobe signals for receive and transmit direction have to be identical. - Complete internal loop The serial data output is physically mirrored back to the serial data input. The data on the external input line are ignored. The logical channels have to be programmed identically. The time and strobe signals for receive and transmit direction have to be identical. User's Manual 137 01.2000 PEB 20320 Detailed Register Description - Channelwise external loop One single logical channel is mirrored logically from serial data input to serial data output. The other channels are not affected by this operation. The data rate for this single logical channel has to be identical for receive and transmit direction. - Channelwise internal loop One single logical channel is mirrored logically from serial data output to serial data input. The other channels are not affected by this operation. The data rate for this single logical channel has to be the same for receive and transmit direction. See Chapter 5.1 and Chapter 5.3.2 for a more detailed discussion of test loops. All loops of the MUNICH32 V3.2 are under complete software control. Loops can be closed and opened via software. Handling of the MUNICH32 V3.2 loops: Switch loops on: RES = IN = ICO = `0' LOC, LOOP, LOOPI PCM, MFL, IM, IA CHANNEL NUMBER for selected loop type don't change the previous values in case of channelwise loops use the selected channel number in case of complete loops use channel number of an active channel. Switch loops off: RES = IN = ICO = `0' LOC = `0', LOOP = LOOPI = `1' PCM, MFL, IM, IA CHANNEL NUMBER IA: don't change the previous values use channel number used with the `switch loop on'. Interrupt Attention; a new interrupt queue is defined by the host. MUNICH32 reads the interrupt queue specification and writes the interrupt information into the new interrupt queue. User's Manual 138 01.2000 PEB 20320 Detailed Register Description IN ICO MFL PCM 0 Initialization Procedure Read the complete time-slot assignment and the channel spec. of the specified channel (channel number). Initialize Channel Only Channel Number IM RES LOC LOOP LOOPI IA 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 0 Channel No. Interrupt Attention Used in conjunction with IN and ICO A new interrupt queue has been defined. Read the interrupt queue specification. Loops 000 001 010 011 100 101 110 111 Only the channel spec. of the selected channel (channel number) is read and reconfigured. Maximum Frame Length Maximum size of a received frame in HDLC, TMB and TMR mode (up to 8192 bytes). A received frame is aborted and an interrupt is generated if the size of a received frame exceeds the MFL value. MFL applies to all channels. No Loop Complete Internal Loop Complete Internal Loop Not Allowed Not Allowed Channelwise int. Loop Channelwise ext. Loop Not Allowed Reset Read the complete time-slot assignment Read all channel specifications Reinitialize all time-slots PCM Highway Format 000 001 010 011 100 101 110 111 Interrupt Mask T1/DS1 24 Time-Slots, 1.536 Mbit/s Not Allowed Not Allowed Not Allowed T1/DS1 24 Time-Slots, 1.544 Mbit/s CEPT 32 Time-Slots, 2.048 Mbit/s 4.096 Mbit/s PCM Format, even Time-Slots 4.096 Mbit/s PCM Format, odd Time-Slots Do not generate the ARACK & ARF interrupt ITS08221 Figure 77 Action Specification User's Manual 139 01.2000 PEB 20320 Detailed Register Description 4.2.2 Interrupt Queue Specification 31 30 29 28 27 26 25 24 23 22 0 0 0 0 0 0 0 0 0 0 15 14 13 12 11 10 9 8 7 6 0 0 0 0 0 0 21 20 19 18 17 16 0 0 0 0 0 0 5 4 3 2 1 0 Interrupt Queue Address Interrupt Queue Address 0 0 n The interrupt queue is specified as a kind of block (queue), starting on a start address (programmable) with a defined length (programmable). Both, the start address and the queue length are programmable in the Interrupt Queue Specification of the Control and Configuration Section. overwrite START ADDRESS (Interrupt Queue Address) interrupt information long word 1 interrupt information long word 2 interrupt information long word 3 length = (n + 1) x 16 long words where 0 n 255 . . . interrupt information long word (n+1)x16 Figure 78 The minimum queue size is 16 long words; the maximum queue size is 4096 long words. For each interrupt arising, the MUNICH32 writes the interrupt information into the interrupt queue, will increment the pointer to the next address in this block automatically and will generate an interrupt pulse at each interrupt occasion. It is up to the processor to read the interrupt informations out of the interrupt queue. If the MUNICH32 arrives at the end of the interrupt queue, it will jump to the start address of the interrupt block again (cyclic queue) and completely overwrite the previous information. Therefore the length of the interrupt queue should be calculated so, that the MUNICH32 will not overwrite information which was not yet read by the processor. User's Manual 140 01.2000 PEB 20320 Detailed Register Description 4.2.3 Interrupt Information The next table shows the bit assignments for the interrupt information long word. 31 30 INT 0 15 14 29 28 27 26 25 24 23 22 21 20 19 18 17 16 4 3 2 1 0 Interrupt Information 13 12 11 10 9 8 7 6 Interrupt Information 5 Channel Number/Direction When an interrupt occurs MUNICH32 sets the INT bit and writes the interrupt information and the channel number into the interrupt circular buffer. At the same time it generates an interrupt pulse. The classes of error (for example host initiated interrupt or CRC error) of a channel in one direction are treated independently of each other. If several interrupt events coincide they will be indicated to the host with one shared interrupt. 31 30 INT 0 15 14 29 28 27 26 VN3 VN2 VN1 FRC 25 24 E7 E6 E5 E4 E3 E2 E1 SB SA 13 12 11 10 9 8 ARACK ARF HI FI IFC SF ERR FO 23 22 21 7 6 5 0 0 RT 20 4 19 3 18 17 16 2 1 X 0 Channel Number Bit assignment for interrupt queue There are 3 classes of bits in the interrupt: 1. Bits present in each interrupt: INT: this bit is always set to `1' VN(3:1): these bits are `000' for version 1.1 `001' for version 2.1 `010' for version 2.2 `100' for version 3.2 `110' for version 3.4 User's Manual 141 01.2000 PEB 20320 Detailed Register Description 2. Action request interrupts ARACK: Action Request Acknowledge; MUNICH32 sets the ARACK bit to indicate that an action request has been serviced. ARF: Action Request Fail; MUNICH32 aborts an ACTION REQUEST, if the required configuration cannot be performed. An action request fail can occur either when the TB buffer is initialized incorrectly or a bus cycle error (BERR = 0) is detected during a configuration access. If ARACK or ARF is set, all bits except INT and VN(3:1) are set to 0. Note: An action request is forbidden during the time a preceding action has not been finished by an ARACK or ARF interrupt or a pulse at the reset pin. 3. Channel specific interrupts These interrupts indicate specific events in the channel indicated by `Channel Number' and receive or transmit direction indicated by RT (RT = `1': receive direction; RT = `1': transmit direction). The interpretation of these interrupts depends on the specification of the channel in which they occur. The following table shows which interrupts can occur in which mode (unused bits are always 0). 31 30 INT 0 29 28 27 26 VN3 VN2 VN1 FRC HDLC 1 0 V.110/X.30 1 0 TMA 1 0 TMB/TMR 1 0 25 24 23 22 21 20 19 18 17 16 E7 E6 E5 E4 E3 E2 E1 SB SA X F F F 0 0 0 0 0 0 0 0 0 0 0 F F F R R R R R R R R R R R F F F 0 0 0 0 0 0 0 0 0 0 0 F F F 0 0 0 0 0 0 0 0 0 0 0 15 14 13 12 11 10 9 8 7 6 5 ARACK ARF HI FI IFC SF ERR FO 0 0 RT HDLC G G V.110/X.30 G G TMA G G TMB/TMR G G User's Manual 4 3 2 1 0 Channel Number TR TR R R TR TR 0 0 X X X X X X TR 0 0 0 TR TR 0 0 X X X X X X TR T 0 0 TR TR 0 0 X X X X X X TR TR 0 0 TR TR 0 0 X X X X X X 142 01.2000 PEB 20320 Detailed Register Description Where `1' `0' `F' `R' means that the bit is always `1' for this mode means that the bit is always `0' for this mode means the bit is fixed by the version number means a bit that can only be set in the receive direction, i.e. may only be `1' if RT is `1' `T' means a bit that can only occur in transmit direction, i.e. may only be `1' if RT is `0' `TR' means a bit that can occur in receive or transmit direction `G' means a bit of an activation request interrupt which cannot be `G' in a channel specific interrupt `X' means a bit fixed by the channel and direction (receive, transmit) of the event it belongs to. The meaning of the interrupt bits depend on the mode. We therefore will discuss them bit for bit and indicate the different meanings in the different modes. FRC: (V.110/X.30 mode, receive direction only) Change of the framing (E, S, X) bits of the V.110/X.30 frame detected. This interrupt is generated whenever a change in the E-, S-, X-bits is detected, but at most one time within one frame of 10 octets, even if there is more than one change within the frame. After detecting a receive abort channel command for one 10-octet frame FRC is also issued. Ex, Sx, X: (V.110/X.30 mode, receive direction only, only in conjunction with FRC) The value of the bits Ex, Sx, X in the received V.110/X.30 frame. If a value changes, e.g. 2 times within the same frame only the final change is reported. If the change was caused by a receive abort channel command all bits are 0. HI: (all modes, all direction) Host initiated Interrupt; this bit is set when the MUNICH32 detects the HI bit in the receive or transmit descriptor and branches to the next descriptor, or starts polling the hold bit if set. FI: 1.1 HDLC, TMB, TMR Receive Direction: FI = 1 indicates, that a frame has been received completely or was stopped by a receive abort channel command or fast receive abort or a HOLD in a receive descriptor. It is set when the MUNICH32 branches from the last descriptor belonging to the frame to the first descriptor of a new frame. It is also set when the descriptor in which the frame finished contained a hold bit, the interrupt is then issued when the MUNICH32 starts polling the hold bit. 1.2 HDLC, TMB, TMR, TMA Transmit Direction: issued if the FE bit is detected in the transmit descriptor. It is set when the MUNICH32 branches to the next transmit descriptor, belonging to a User's Manual 143 01.2000 PEB 20320 Detailed Register Description new frame, or when it starts polling the hold bit if set in conjunction with the FE bit; ERR and FI are set if a transmit descriptor contains a HOLD bit no FE bit IFC: (HDLC mode, receive direction only) Idle/Flag Change; an interrupt is generated in HDLC if the device changes the interframe time-fill (ITF) state. After reset the device is in the ITF idle state. It changes to the ITF flag state if it receives 2 consecutive flags with or without shared zeroes. It changes back to the ITF idle state upon reception of 15 contiguous `1'-bits or when a receive abort channel command is active during 15 received bits. SF: (HDLC mode, receive direction only, always in conjunction with FI) Short frame detected A frame with 16 bits between start flag and end flag or end abort flag for CRC16 32 bits between start flag and end flag or end abort flag for CRC32 has been detected. The sequences 7E 7FH and 7E FEH and 7E FFH are also short frames. SF is always in conjunction with ERR except for the frames 7E00 007EH for CRC16 7E00 0000 007EH for CRC32 ERR: always in conjunction with FI = 1 1.1 HDLC mode Receive Direction One of the following receive errors occurred - FCS of the frame was incorrect - the bit length of the frame was not divisible by 8 - the byte length exceeded MFL - the frame was stopped by 7FH - the frame could only be partly stored due to internal buffer overflow of RB - the frame was ended by a receive abort channel command - the frame could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the frame. - the frame was aborted by a fast receive abort channel command A more detailed error analysis can be done by the status information in the receive descriptor. 1.2 HDLC mode Transmit Direction one of the following transmit errors occurred: - the last descriptor had HOLD = 1 and FE = 0 - the last descriptor had NO = 0 and FE = 0 User's Manual 144 01.2000 PEB 20320 Detailed Register Description 2.1 V.110/X.30 mode Receive Direction one of the following receive errors occurred: - data could only partly stored due to internal buffer overflow of RB - 3 consecutive frames had an error in the synchronization pattern (loss of synchronism) - a fast receive abort channel command was issued - the data could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the data - a receive abort channel command was active for at least 3 consecutive frames A more detailed error analysis can be done by the status information in the receive descriptor. 2.2 V.110/X.30 mode Transmit Direction one of the following transmit errors occurred - the last descriptor had a HOLD = 1 or FE = 1 - the last descriptor had FE = 0 and NO = 0 3.1 TMA mode Receive Direction one of the following errors occurred - the data could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the data - a fast receive abort channel command was issued 3.2 TMA mode see Chapter 1.2 Transmit Direction 4.1 TMB/TMR mode Receive Direction always in conjunction with FI = 1 one of the following receive errors occurred - the bit length of the frame was not divisible by 8 - the frame could only be partly stored due to internal buffer overflow of RB - the frame could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the frame - the frame was aborted by a fast receive abort channel command A more detailed error analysis can be done by the status information in the receive descriptor. 4.2 TMB/TMR mode see 1.2 FO: Transmit Direction 1.1 HDLC, TMB, TMR Receive Direction The MUNICH32 has discarded one or more whole frames or short User's Manual 145 01.2000 PEB 20320 Detailed Register Description frames or change of interframe time-fill informations due to inaccessibility of the internal buffer RB. 1.2 HDLC, TMB, TMR Transmit Direction The MUNICH32 is unable to access the shared memory in time or has detected a bus cycle error (BERR = 0) during a read access on the transmit data section. The current erroneous frame is aborted with a `0' and 14 `1' for HDLC, with 00 for TMB and 0000 for TMR; afterwards interframe time fill is sent until the MUNICH32 can access again the shared memory. The MUNICH32 will read the transmit data from the location which should be accessed before the Tx-FO or BERR happened and transmit the rest of the erroneous frame. 2.1 V.110/X.30 Receive Direction The MUNICH32 has discarded a loss of synchronism information or a change of a E-, S-, X-bits information due to inaccessibility of the internal buffer RB. 2.2 V.110/X.30 Transmit Direction The MUNICH32 is unable to access the shared memory in time or has detected a bus cycle error (BERR = 0) during a read access on the transmit data section. It generates 3 10-octet frames with framing errors and restarts with the next error-free transmit data. 3.1 TMA Receive Direction The MUNICH32 has discarded data due to inaccessibility of the internal buffer RB. 3.2 see Chapter 1.2 The following table shows which interrupt bits are masked by which bits in the channel specification. 31 30 INT 29 28 27 26 VN3 VN2 VN1 FRC 25 24 23 22 21 20 19 18 17 16 E7 E6 E5 E4 E3 E2 E1 SB SA X 2 1 0 Receive CH - Transmit 15 14 13 12 11 10 9 8 ARACK ARF HI FI IFC SF ERR FO 7 6 5 0 0 RT 4 3 Channel Number Receive FIR IFC SFE RE RE FIT TE Transmit User's Manual - - TE 146 01.2000 PEB 20320 Detailed Register Description General IM IM 0 0 3 4 2 1 0 Channel Number RT 0 VN(3...1) FRC E7 E6 E5 E4 E3 E2 E1 SB SA X ARACK ARF HI FI IFC SF ERR F0 INT 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 Framing Bits Changed Channel Number V.110/X30 mode received E, S, X Bits changed Identifies the channel where the interrupt occured. Action Request Acknowledge Direction Action request has been completed successfully. 0 Transmit Interrupt 1 Receive Interrupt Action Request Failed Action request could not be completed successfully. Overflow/Underflow Internal buffer not available Silicon Version Number Protocol Error 000 001 010 100 e.g. CRC error, frame aborted, loss of sync. MFL exceeded Internal buffer overflow/underflow V1.1 V2.1 V2.2 V3.2 Short Frame Host Initiated Interrupt HI Bit in the Rcv./Xmt. descriptor was set HDLC mode, in conjunction with FI (empty HDLC frame or incorrect HDLC frame, nothing stored in memory) Frame Indication Interframe Timefill Change End of receive or transmit frame indication HDLC receiver detected change in ITF state Valid Interrupt Entry MUNICH32 sets this Bit with every entry to the interrupt circular queue Software should dear this Bit after reading ITS08222 Figure 79 Interrupt Information User's Manual 147 01.2000 PEB 20320 Detailed Register Description 4.2.4 Time Slot Assignment (Read only once after each action request pulse with an action specification with set IN or RES bit) The time slot assignment provides the cross reference between the 32 (24) time slots of the PCM highway and the data channels (up to a maximum number of 32). The data channels can be composed of different receive and transmit time slots, which have individual bit rates. With the concept of subchanneling, MUNICH32 can realize flexible transmission from 8 kbit/s up to 2.048 Mbit/s per channel. 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 0 0 TTI Transmit Channel Number Transmit Fill Mask time slot 0 0 0 TTI Transmit Channel Number Transmit Fill Mask time slot 1 0 0 TTI Transmit Channel Number Transmit Fill Mask time slot 31 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 0 RTI Receive Channel Number Receive Fill Mask time slot 0 0 0 RTI Receive Channel Number Receive Fill Mask time slot 1 0 0 RTI Receive Channel Number Receive Fill Mask time slot 31 Fill/Mask Code: User's Manual For bit rate adaption the fill/mask code determines the number of bits and the position of these bits within the time slot. For all modes except TMA the bits selected by Fill/Mask = 1 in the slots of a channel are concatenated, those with Fill/Mask = 0 are ignored/tristated in receive/transmit direction. For TMA the bits with Fill/Mask = 0 are received as `1'-bits, in transmit direction these bits are overwritten with `Z' (see Chapter 2.4 for more details). 148 01.2000 PEB 20320 Detailed Register Description Channel Number: The channel number identifies the data channel. Its transmission mode is described in the respective channel specification. TTI: Transmit Time slot Inhibit; setting this bit to `1' causes MUNICH32 to tristate the transmit time slot. The data is not destroyed but sent in the next not tristated time slot allocated to this channel. RTI: Receive time Slot Inhibit; setting this bit to `1' causes MUNICH32 to ignore the received data in the time slot. The channel is not processed in this time slot. 4.2.5 Channel Specification (Read only once after each activation request pulse with an action specification with set IN, RES or ICO bit; RES: the channel specifications of all channels; IN, IC0: the channel specification of the channel indicated in the action specification) 31 30 29 28 27 26 25 24 23 Interrupt Mask 22 21 20 19 18 17 16 NITBS RI TI TO TA TH RO RA 0 0 0 0 0 0 3 2 1 0 FRDA FTDA 0 0 0 0 0 0 15 14 13 12 11 10 0 0 9 0 8 0 7 6 TFLAG TFLAG /NSF /CS INV TFLAG CR C 5 4 TRV FA Mode IFT F FRDA FTDA 0 0 0 0 0 0 0 0 0 0 ITBS Interrupt Mask: 7 6 5 4 3 2 1 0 - SFE IFC CH TE RE FIR FIT These bits mask the bits in the interrupt information long word according to the table at the end of Chapter 4.2.3 (interrupt information). User's Manual 149 01.2000 PEB 20320 Detailed Register Description If an event leads to an interrupt with several bits set (e.g. FI and ERR) masking only a proper subset of them (e.g. ERR) will lead to an interrupt with the nonmasked bits set (e.g. FI). If all bits of an event are masked, the interrupt is suppressed. The interrupt mask is therefore bit specific and not event specific. NITBS: New ITBS value; if this bit is set the individual transmit buffer size ITBS is valid and a new buffer field of TB is assigned to the channel. In this process first the occupied buffer locations of the channel are released and then according to ITBS a new buffer area is allocated. If there is not enough buffer size in TB (occupied by other channels) the process will be aborted and an action request failure interrupt is generated. After aborting no buffer size is allocated to the channel. For preventing action request failure enough buffer locations must be available. This can be done by reducing the buffer size of the other channels. To avoid transmission errors all channels to be newly configured must be deactivated before processing. Note: ITBS has to be set to `0' if NITBS = `0'. NITBS should be set to `0' in conjunction with a transmit abort channel command. The bits RI, TI, TO, TA, TH, RO, RA are the so called channel command bits. They allow the channel to be initialized, aborted or reconfigured at the serial side as well as at the P side. These bits can be decomposed in 3 independent command groups: RI, RO, RA form the receive command group TO, TI, TA the first transmit command group and TH is the second transmit command group. We will discuss these bits according to the groups. 1. Receive command group (6 commands) - receive clear RI = 0, RO = 0, RA = 0 (clears a previous receive abort or receive off condition, affects only the serial interface) The effect of this command depends on the previous history of the channel * if the channel was never initialized by a receive initialization command it has no effect * if it was initialized previously it clears a receive off or receive abort condition set by a previous channel command * if no receive off or receive abort condition is set it has no effect. - fast receive abort RI = 0, RO = 0, RA = 1 (clears a previous receive abort or receive off condition, affects only the DMA interface) This abort is performed in the DMA controller and does not interfere with the reception on the serial interface and the transfer of the data into the receive buffer. If this abort is detected the current receive descriptor is suspended with an abort status (RA bit set User's Manual 150 01.2000 PEB 20320 Detailed Register Description to `1') followed by a branching to the new descriptor (FRDA) defined in the channel specification of the CCS. For HDLC, TMB, TMR the rest of a frame which was only partially transferred before suspension of the receive descriptor is aborted, the new descriptor is related to the next frame. An interrupt with FI, ERR is issued. For V.110/X.30 and TMA data bits might get lost. An interrupt with ERR is issued. - receive off RI = 0, RO = 1, RA = 0 (clears a previous receive abort condition, sets off condition, affects only the serial interface) This channel command sets the receiver into the receive off condition. The receive channel is disabled completely at the serial interface, i.e. the receive deformatter RD is reset and the receive buffer RB is not accessed for this channel. A currently processed frame (HDLC, TMB, TMR mode) is not properly finished with any status information. The data stored in the RB at that time is still transferred to the shared memory. After the receive off condition is cleared by another channel command: * in HDLC, TMB, TMR (V.110/X.30, TMA) mode the device waits for a new frame (10octet frame, nothing) to begin and then starts filling RB again. If the receive off command lead to an improper finishing of a frame (data, data), the new frame (data, data) is concatenated with the finished one. To avoid this problem there are two suggestions: a) issue a receive abort channel command and wait for 32 (240, 8) bits for this channel to be processed before issuing the receive off command. b) wait in the receive off condition until the RB is emptied for this channel (i.e. for at most 8 PCM frames if the MUNICH32 has sufficient access to the shared memory) and leave the receive off condition by a receive initialization command. The receive off channel command is ignored in case of any kind of loop. - receive abort RI = 0, RO = 1, RA = 1 (clears a previous receive off condition, sets a receive abort condition, affects only the serial interface) This receive channel command sets the receiver into the receive abort condition. In this condition it receives (instead of the normally received bits) logical `1' bits for HDLC logical `0' bits for V.110/X.30, TMB, TMR logical `0' bits for unmasked bits in TMA mode logical `1' bits for masked bits in TMA mode irrespective of the INV bit. This leads to * For HDLC: a currently processed frame is aborted after 7 received bits for this channel, leading to a RA set in the status of the frame and an interrupt with set FI and ERR bits only or to an interrupt with set SF, FI and ERR bits. If the receiver was User's Manual 151 01.2000 PEB 20320 Detailed Register Description * * * * in the flag interframe time-fill state it will lead to an interrupt with set IFC bit after 15 received bits. For V.110/X.30: if the receiver was in the synchronized frame state it will go to the unsynchronized state after 240 bits and issue a LOSS bit in the status of the current receive descriptor. It will also issue an interrupt with set ERR bit and (unless all E-, S-, X-bits were 0 previously) issue one or two interrupts with FRC set and having all E-, S-, X-bits at 0 in the last one. For TMB: a currently processed frame is aborted after 15 received bits for this channel, leading to an interrupt with FI set but ERR on 0, the status of this frame is always 00H. For TMR: a currently processed frame is aborted after 31 received bits for this channel, leading to an interrupt with FI set but ERR on 0, the status of this frame is always 00H. For TMA: the device receives the inverse of the fill/mask bits programmed for this channels. Note 1: It is advisable to clear the receive abort condition via a receive off command for V.110/X.30 mode, the TMB and the TMR mode. 2. After issuing a receive abort channel command it is advisable to stay in this condition during at least 16, 240, 16, 32, 8 bits of the channel for HDLC, V.110/ X.30, TMB, TMR, TMA respectively. - receive jump RI = 1, RO = 0, RA = 0 (clears a previous receive abort or receive off condition, affects only the DMA interface) During normal operation branching to a new descriptor (FRDA) is possible without interrupting the current descriptor and aborting the received frame (HDLC, TMB, TMR) or received data (V.110/X.30, TMA). The DMA controller will proceed finishing the current receive descriptor as usual either with a frame end condition or with the corresponding data buffer completely filled and afterwards branch to the new descriptor specified by FRDA. Thus a received frame may be splitted on `old' and `new' descriptors. - receive initialization RI = 1, RO = 0, RA = 1 (clears a previous receive abort or receive off condition, affects the DMA and serial interface) Before the MUNICH32 has got a receive initialization command it will not receive anything properly in a channel. This command should therefore be the first channel command after a pulse at the reset pin for a channel to be used. FRDA is then the address of the starting point of the receive descriptor chaining list. If the command is issued during normal operation it only affects the DMA interface. The current receive descriptor is suspended without writing the second long word with the status, no interrupt is generated. For HDLC, TMB, TMR the rest of a frame which was only partially transferred before the suspension of the receive descriptor is User's Manual 152 01.2000 PEB 20320 Detailed Register Description aborted, the new descriptor (FRDA) is related to the next frame. For V.110/X.30 and TMA data bits might get lost. General Notes to Receive Commands: 1. After a pulse at the reset pin a channel having a time slot with RTI = 0 should be issued receive off commands until it is supposed to be used. 2. When it is supposed to be used it should be issued a receive initialize command before using any other receive channel command. 3. To shut down a channel in receive direction one should first set it into the receive abort condition for the time specified there and then set it into the receive off condition. 4. Before changing the MODE, CRC, CS, TRV, INV, TFLAG bits of a channel or its RTI or time slot assignment or its fill/mask bits it should have been shut down. The bits should be changed while issuing the receive off command. 5. To revive a channel after it has been shut down one should use the receive initialization command. 6. To switch to a new starting point of a receive descriptor chain one should preferably use the receive jump command, only exceptionally the fast receive abort command and never the receive initialize command. 7. To issue channel commands not affecting the receive side one should issue - a receive clear command if neither a receive off nor a receive abort condition is set - a receive off command if a receive off condition is set - a receive abort command if a receive abort condition is set. 8. Combinations of the bits RI, RO, RA not in this description are reserved and are not allowed to be used. 2. First Transmit Command Group - transmit clear TI = 0, TO = 0, TA = 0 (clears a previous transmit abort or transmit off condition, affects only the serial interface) * if the channel was never initialized by a transmit initialization command it has no effect * if it was initialized previously it clears a transmit off or transmit abort condition set by a previous channel command * if no transmit off or transmit abort condition is set it has no effect - fast transmit abort TI = 0, TO = 0, TA = 1 (clears a previous transmit abort or transmit off condition, affects only the DMA interface) This abort is performed in the DMA controller and does not interfere with the current transmission on the serial interface and the transfer between the TF and TB. If this abort is detected the current descriptor is suspended and the frame or data transferred to the TB is aborted. The next frame beginning in the transmit descriptor (FTDA) defined in the channel specification of the CCS will be started immediately. User's Manual 153 01.2000 PEB 20320 Detailed Register Description For HDLC, TMB, TMR the first part of the frame of the suspended descriptor is sent and append by 011 1111 1111 111 for HDLC at least 00H for TMB at least 00 00H for TMR Afterwards the next frame is started. For V.110/X.30 three 10-octet frames with errors in the synchronization pattern are sent after the data of the suspended descriptor, afterward the next data are sent in correct frames. For TMA a TFLAG (FA = 1) or FFH (FA = 0) is sent in at least one time slot after the data of the suspended descriptor, afterwards the next data are sent. - transmit off TI = 0, TO = 1, TA = 0 (clears a previous transmit abort condition, sets a transmit off condition, effects only the serial interface) The transmit channel is disabled immediately, i.e. the transmit formatter is reset and the transmit buffer is not accessed for this channel. The output time slots are tristated. Upon leaving the transmit off mode the transmit link list must be initialized by a transmit reinitialize command. Otherwise the transmission will be started with the remaining data still stored in TB and continue with the old link list. If a loop condition is set the transmit off does not reset the transmit formatter, it only tristates the serial output line. After the transmit off condition is cleared by the transmit initialize command. * In HDLC, TMB, TMR, V.110/X.30 the device starts with the interframe time-fill 7E for HDLC and IFTF = 0 FF for HDLC and IFTF = 1 00 for TMB, TMR, V.110/X.30 and then with the frame in the descriptor at FTDA. For V.110/X.30 this descriptor must have the V.110-bit set and point to the E-, S-, X-bits, the data are then at the next transmit descriptor. * In TMA mode the device starts with the interframe time-fill TFLAG for FA = 1 for FA = 0 FFH and then with the data in the descriptor at the FTDA. User's Manual 154 01.2000 PEB 20320 Detailed Register Description - transmit abort TI = 0, TO = 1, TA = 1 (clears receive off condition, sets transmit abort condition, affects only the serial interface) This abort is performed in the transmit formatter at the serial interface. The currently transmitted frame is aborted by 011 1111 1111 1111 for HDLC for TMB 00H for TMR 0000H 3 frames with erroneous synchronization pattern for V.110/X.30 TFLAG for TMA, FA = 1 FF for TMA, FA = 0. Afterwards or - if no frame is currently sent directly inter frame time fill: 7E for HDLC and IFTF = 0 FF for HDLC and IFTF = 1 00 for TMB, TMR, V.110/X.30 TFLAG for TMA, FA = 1 FF for TMA, FA = 0 is sent. During transmit abort the TF does not access the transmit buffer. The handling of the link list is not affected by the transmit abort, i.e. the device keeps the TB full. When the transmit abort is withdrawn the transmit formatter continues the transmission with the data stored in TB. In the case of HDLC or TMB or TMR mode the remaining data of the aborted HDLC or TMB frame is sent as a new independent frame. To avoid this problem the link list must be reinitialized by a transmit initialization command together with the revoking of the transmission abort. Another proper use of the transmit abort command consists in setting the last descriptor of the last frame to be transmitted with HOLD = 1 and waiting for the device to poll the HOLD bit (ITBS + 2) times where ITBS is the number of long words assigned to this channel currently. Afterwards TB is empty and the transmit abort then issued does not abort a currently sent frame. The same procedure can also be used for the transmit off command. - transmit jump TI = 1, TO = 0, TA = 0 (clears a transmit off and transmit abort condition, affects only the DMA interface) This bit is set only during normal operation. Then MUNICH32 branches to the transmit descriptor (FTDA) specified in the CCS after finishing the current transmit descriptor without interrupting or aborting the transmitted frame. The DMA controller will proceed finishing the current transmit descriptor as usual and afterwards branch to the new descriptor specified by FTDA. If the current descriptor does not include a frame end (FE = 0) (HDLC, TMB, TMR) the DMA controller will link the following data section(s) of the `new' descriptor chain to the opened frame. This may generate unexpected frames. User's Manual 155 01.2000 PEB 20320 Detailed Register Description - transmit initialization TI = 1, TO = 0, TA = 1 (clears a previous transmit abort condition, affects the DMA interface and the serial interface) Before the MUNICH32 has got a transmit initialization command it will not transmit anything properly in the channel. This command should therefore be the first channel command after a pulse at the reset pin for a channel to be used. FTDA is then the address of the starting point of the transmit descriptor for chaining list. In this case the transmit initialize command should be accompanied by the NITBS bit set and a reasonable value for ITBS (0 < ITBS < 64). If the command is issued during normal operation it only affects the DMA. The MUNICH32 stops processing of the current link list and branches to the transmit descriptor at the FTDA address. The data stored in the TB are discarded and the TB is filled with the data of the new descriptor. 3. Second Transmit Command Group - Transmit HOLD TH; setting this bit causes the device to finish transmission of the current frame (HDLC, TMB, TMR mode) the current data (TMA -mode) or leads to an abort with 3 frames with `0'-bits (V.110/X.30-mode). Afterwards for HDLC mode and IFTF = 1 FFH fill characters HDLC mode and IFTF = 0 7EH fill characters V.110/X.30-mode 00H fill characters TMA mode and FA = 1 TFLAG fill characters TMA mode and FA = 0 FFH fill characters TMB/TMR 00H fill characters are sent until TH is withdrawn by a further action specification affecting the channel specification of this channel. Afterwards no further access to the TB from TF is done, therefore no further data are fetched from the shared memory and the polling of a possible hold bit in the transmit descriptor stops. To send necessary frames/data before the transmit hold is active one should use the proper procedure described under the transmit abort command. General Notes to Transmit Commands: 1. After a pulse at the reset pin a channel having a time slot with TTI = 0 should be issued transmit off commands and TH = 1 until it is supposed to be used. 2. When it is supposed to be used it should be issued a transmit initialization command and TH = 0 before using any other transmit channel commands (together with NITBS = 1, ITBS 0). 3. To shut down a channel in transmit direction one should first set it into the transmit abort condition or use the TH bit with the proper procedure. One should leave it in User's Manual 156 01.2000 PEB 20320 Detailed Register Description 4. 5. 6. 7. 8. 9. 10. that condition for 32, 240, 32, 32, 8 bits for HDLC, V.110/X.30,TMB, TMR, TMA respectively and then set it into the transmit off condition. Before changing the MODE, CRC, CS, TRV, INV, TFLAG bits or TTI or time slot assignment or the fill/mask bits or the ITBS the channel should be shut down. The bits should be changed while issuing the transmit off command. To revive a channel after it has been shut down one should use the transmit initialization command. For V.110/X.30-mode the first descriptor after reviving from shut down or initialization after reset must have the V.110-bit set and contain the E-, S-, X-bits. To switch to a new starting point of a transmit descriptor chain one should preferably use the transmit jump command, only exceptionally the fast transmit abort command and never the transmit initialize command. To issue channel commands not affecting the transmit side one should issue - TH with the last set value - a transmit clear command if neither a transmit off nor a transmit abort condition is set - a transmit off if a transmit off condition is set - a transmit abort if a transmit abort condition is set. Bit combinations in the first transmit command group not described are reserved. Set NITBS = 1 preferably in conjunction with a transmit initialize and transmit clear command if TB is to be newly configured, otherwise set NITBS = 0. TFLAG: Transparent mode Flag; these bits are only used in the transparent mode A and constitute the fill code for flag stuffing and for flag filtering. These bits must be set to `0' if subchanneling is used in transparent mode A. Bit No. 15 is the first bit of the flag to be received/transmitted. NSF: No Short Frame suppression; NSF = 1 is only allowed in combination with HDLC mode and CS = 1. In this mode the MUNICH32 transfers all data to the shared memory even if only one byte (or more) per `frame' is received. No short frame interrupt and no short frame status bit will be generated in this case. Note:CRC is still calculated and checked and e.g. a frame of 1 or 2 byte length (in CRC16 mode) will always cause an FI + ERR interrupt. User's Manual 157 01.2000 PEB 20320 Detailed Register Description Receive Frame Examples: a) 0x7E, data byte, 0x7E - data byte copied to shared memory + frame end - status SF-bit set - no SF indication interrupt generated - FI indication interrupt generated - ERR interrupt generated due to wrong CRC' b) 0x7E, data byte = 0xFC (or 0xFD or 0x7F), 0x7E - no data byte copied to shared memory - SF and FI interrupt generated CS: CRC Select; only used in HDLC mode. Setting this bit to `1' causes the MUNICH32 to transfer the CRC bits to the data section in the shared memory. In receive direction the CRC check is carried out whereas in transmit direction the CRC generation is suppressed, see Chapter 2.4 for more details. INV: Inversion; If this bit is set, all data of the channel transmitted or received by the MUNICH32 is inverted. CRC: Cyclic Redundancy Check; in HDLC mode this bit determines the CRC generator polynomial: When the CRC bit is set to `1' the 32-bit CRC is performed, otherwise the 16-bit CRC; for TMB/TMR mode this bit distinguishes: TMB: CRC = `0' TMR: CRC = `1' for all other modes this bit has to be set to `0'. User's Manual 158 01.2000 PEB 20320 Detailed Register Description TRV: Transmission Rate of V.110/X.30. These signals determine the number of repeated D-bits in a V.110/X.30 frame. Table 9 TRV No. of Repetitions Transmission Rate 00 01 10 11 7 3 1 0 600 bit/s 1200 bit/s 2400 bit/s 4.8, 9.6, 19.2, 38.4 kbit/s Note: In the other modes these bits must be set to `00'. FA: Flag Adjustment selected (in HDLC mode) or flag filtering (selected in transparent mode A only if all fill/mask bits of the corresponding slots are `1'). In all other modes this bit must be set to `0'. If flag adjustment is selected in HDLC mode the number of interframe time-fill characters is FNUM minus one eighth of the number of zero insertions in the frame proceeding the interframe time-fill and belonging to the same transmit descriptor as FNUM. If flag filtering is selected and fills a physical time slot in transparent mode A the flag specified in TFLAG is recognized and extracted from the data stream. In transmit direction the flag TFLAG is sent in all exception conditions, i.e. abort, idle state etc.; if flag filtering is not selected `1'-bits are sent in this case. Flag filtering is only allowed if all fill/mask codes are set to `1', i.e. subchanneling is not allowed. If flag filtering is not selected the bits in TFLAG have to be set to 0 for TMA. MODE: Defines the transmission mode: 11: HDLC mode 10: V.110/X.30 mode 00: Transparent mode A 01: Transparent mode B or transparent mode R. IFTF: Interframe Time-Fill: this bit determines the interframe HDLC mode: IFTF = 0:AEH characters are sent as interframe time-fill IFTF = 1:FFH characters are sent as interframe time-fill. FRDA: First Receive Descriptor Address points to the beginning of the receive data chaining list. This descriptor is only interpreted with a fast receive abort or a receive jump or a receive initialization command. It is read but ignored with any other receive channel command. User's Manual 159 time-fill for 01.2000 PEB 20320 Detailed Register Description FTDA: First Transmit Descriptor Address points to the beginning of the transmit data chaining list. This descriptor is only interpreted with a fast transmit abort or a transmit jump or a transmit initialization command. It is read but ignored with any other transmit channel command. ITBS: Individual Transmit Buffer Size; for undisturbed transmission an on-chip transmit buffer with a total size of 64 long words stores the data before formatting and transmitting. The individual buffer size specifies the part of the on chip transmit buffer allocated to the channel. This allows a variable data buffer size if NITBS = 0, ITBS has to be set to 0 also; it is then read but ignored. (see Chapter 2.3). Mode IFTF TRV FA TFLAG CS INV CRC 0 SFE IFC CH TE RE FIR FIT NITBS RI TI TO TA TH RO RA 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 FRDA (First Receive Descriptor Address) FTDA (First Transmit Descriptor Address) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ITBS (buffer size) New ITBS Value Rcv./Xmt. Commands Transparent Mode Flags Interframe Rcv. Commands Timefill New Xmt. buffer size Fill code for flags in 0 7E (flags) (ITBS valid) (RI, RO, RA): transp. mode A (TMA only) 000 Rcv. Clear 1 FF (ones) 001 Fast Rcv. Abort (HDLC mode) Interrupt Mask CRC Select 010 Rcv. OFF SFR: Short Frame (R) CRC Generated/Stripped 0 011 Rcv. Abort Mode CRC to/from Data Section 1 IFC: Idle/Flag Change (R) 100 Rcv. Jump (HDLC mode only) CH: V.110 Frg. Chg. (R) 0 0 TMA 101 Rcv. Init. TE: ERR Interrupt (T) 0 1 TMB/TMR 110 Not Allowed RE: ERR Interrupt (R) 1 0 V.110/X30 Inversion 111 Not Allowed FIR: FI Interrupt (R) 1 1 HDLC Mode All Rcv. and Xmt. data Bits FIT: FI Interrupt (T) First Xmt. Commands in this channel are inverted. (R) Receiver Interrupt Flag Adjustment/Filtering (T) Transmitter Interrupt (TI, TO, TA): FNUM interframe timefill CRC Polynom 000 Xmt. Clear characters in HDLC mode, 001 Fast Xmt. Abort 16 Bit CRC (HDLC mode) 0 or TFLAG filtering in TMA 010 Xmt. OFF 32 Bit CRC (HDLC mode) 1 011 Xmt. Abort TMB 0 100 Xmt. Jump TMR 1 Transmission Rate of V.110/X30 101 Xmt. Init. 0 0 600 bit/s, 7 Repetitions 110 Not Allowed 0 1 1200 bit/s, 3 Repetitions 111 Not Allowed 1 0 2400 bit/s, 1 Repetitions 1 1 4.8, 9.6, 19.2, 38.4 kbit/s, 2 nd Xmt. Commands no Repetition (TH = 1) : Xmt. Hold ITS08223 Figure 80 Channel Specification User's Manual 160 01.2000 PEB 20320 Detailed Register Description 4.2.6 Current Receive and Transmit Descriptor Address 31 16 15 0 Current Receive Descriptor Address Channel 0 . . . Current Receive Descriptor Address Channel 31 Current Transmit Descriptor Address Channel 0 . . . Current Transmit Descriptor Address Channel 31 For easier monitoring of the link lists the addresses of the just processed descriptors are written into the CCS. MUNICH32 changes the current descriptor address at the same time when it branches to the next descriptor. User's Manual 161 01.2000 PEB 20320 Detailed Register Description 4.3 31 Transmit Descriptor 30 29 28 27 26 25 24 23 FE HOLD HI 22 21 20 19 18 17 16 4 3 2 1 0 NO Transmit Data Pointer Next Transmit Descriptor Pointer 15 14 13 12 11 V.110 0 0 0 CSM 10 9 8 7 6 5 FNUM Transmit Data Pointer Next Transmit Descriptor Pointer FE: Frame End; this bit is valid in all modes. It indicates that after sending the data in the transmit data section - the device generates an interrupt with FI bit set for HDLC, TMB, TMR, TMA ERR bit set for V.110/X.30 - the device then sends for HDLC, IFTF = 0 * (FNUM + 1) x 7EH * 7E, (FNUM - 1) x FFH, 7E for HDLC, IFTF = 1, FNUM 1 * 7E for HDLC, IFTF = 1, FNUM = 0 for TMB, TMR (FNUM 1) * (FNUM + 1) x 00H * 000H for TMR, FNUM = 0 * (FNUM + 1) x TFLAG for TMA, FA = 1 for TMA, FA = 0 * (FNUM +1) x FFH * three frames with synchronization errors for V.110/X.30 before starting with the data of the next transmit descriptor. If the data of the next transmit descriptor are not available in time (e.g. because the descriptor has FE and HOLD set) the device sends the interframe time-fill indefinitely. User's Manual 162 01.2000 PEB 20320 Detailed Register Description HOLD: If the MUNICH32 detects a hold bit it - generates an interrupt with ERR bit set if FE = 0 or V.110/X.30 mode - sends the data in the current transmit data section - generates the FCS bits for HDLC and CS = 0 and CSM = 0 - the device then sends at least for HDLC, IFTF = 0 * (FNUM + 1) x 7EH for HDLC, IFTF = 1 * 7E, FNUM x FFH for TMB, TMR (FNUM 1) * (FNUM + 1) x 00H * 0000H for TMR, FNUM = 0 * (FNUM + 1) x TFLAG for TMA, FA = 1 for TMA, FA = 0 * (FNUM + 1) x FFH * three frames with synchronization errors for V.110/X.30. - It polls the HOLD bit and the next transmit descriptor address, but does no branch to a new descriptor until the HOLD bit is reset. The next transmit descriptor address is read but not interpreted as long as HOLD = 1. Therefore it can be changed together with setting HOLD = 0. The polling occurs at most every 8 valid clock cycles of the channel and corresponds with internal requests from TF to TB. - The device sends interframe time-fill until HOLD = 0 is polled. The HOLD condition is also discarded if a transmit jump, fast transmit abort or transmit initialization command is detected during the polling. The MUNICH32 then branches to the transmit descriptor determined by FTDA even though the HOLD bit of the current transmit descriptor may still be `1'. HI: Host initiated Interrupt; if the HI bit is set, MUNICH32 generates an interrupt with set HI bit after transferring all data bytes. NO: This byte number defines the number of bytes stored in the data section to be transmitted. A transmit descriptor and the corresponding data section must contain at least either one data byte or a frame end indication. Otherwise an interrupt with set ERR bit is generated. V.110: This bit indicates that in the corresponding data section the E-, S- and X-bits of the following V.110/X.30 frame are stored. MUNICH32 reads these bits and inserts them into the next possible V.110/X.30 frame. The data section may contain only two bytes specified in the next figure. The first transmit descriptor after a transmit initialization channel command must have this bit set if it revives the channel from a transmit off condition or after a pulse at the reset pin. User's Manual 163 01.2000 PEB 20320 Detailed Register Description Intel Mode 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 E7 E6 E5 E4 E3 E2 E1 SB SA X 0 0 0 0 0 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Motorola Mode 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 SA X 0 0 0 0 0 0 E7 E6 E5 E4 E3 E2 E1 SB CSM: CRC Select per Message: This bit is only valid in HDLC mode with CS = 0 and only in conjunction with the FE bit set. If set, it means that no FCS is generated automatically for the frame finished in this transmit descriptor. FNUM: FNUM denotes the number of interframe time-fill characters between 2 HDLC or TMB frames. For X.30/V.110 these bits have to be set to `0'. FNUM = 0 means that after the current frame only 1 character (7EH for HDLC and 00H for TMB, 000H for TMR, TFLAG, TFLAG for TMA, FA = 1; FFH for TMA, FA = 0) is sent before the following frame (shared flags). FNUM = 1 means that after the current frame 2 characters (7EH 7EH for HDLC and 00H 00H for TMB and TMR, TFLAG, TFLAG for TMA, FA = 1; FF FFH for TMA, FA = 0) are sent before the following frame (non shared flags). FNUM = 2 means that after the current frame 3 characters (7EH 7EH 7EH (IFTF = 0) or 7EH FFH 7EH (IFTF = 1) for HDLC and 00H 00H 00H for TMB and TMR, TFLAG, TFLAG, TFLAG for TMA, FA = 1; FF FF FFH for TMA, FA = 0) are sent. User's Manual 164 01.2000 PEB 20320 Detailed Register Description FNUM = k means that after the current frame k + 1 characters are sent for ITFT = 0 and HDLC (k + 1) times 7EH 7EH, (k - 1) times FFH, 7EH for ITFT = 1 and HDLC for TMB, TMR (k + 1) times 00H (k + 1) times TFLAG for TMA, FA = 1 (k + 1) times FFH for TMA, FA = 0. For HDLC mode FNUM is reduced by one eight of the number of zero insertions if FA is set. If the reduction would result in a negative number of interframe time-fill characters it is set to 0. Transmit Data Pointer: This 32-bit pointer contains the start address of the transmit data section. Although MUNICH32 works only long word oriented, it is possible to begin a transmit data section at an uneven address. The two least significant bits (ADD) of the transmit data pointer determine the beginning of the data section and the number of data bytes in the first long word of the data section, respectively. ADD: 00 = 4 bytes 01 = 3 bytes 10 = 2 bytes 11 = 1 byte MUNICH32 reads the first long word and discards the unused least significant bytes. The NO establishes (determines) the end of the data section, whereas the remainder of I (NO ADD) / 4 I defines the number of bytes in the last long word of the data section. MUNICH32 reads the last long word and discards the unused most significant bytes of the last long word. If the first access is the same as the last access, ADD specifies the beginning of the data section and NO the number of data bytes in the long word. All unused bytes are discarded. User's Manual 165 01.2000 PEB 20320 Detailed Register Description For example (Intel mode): 1) ADD = 01, NO = 8 11 10 01 00 byte 2 byte 1 byte 0 - byte 6 byte 5 byte 4 byte 3 - - - 3 long words are read byte 7 2) ADD = 00, NO = 8 11 10 01 00 byte 3 byte 2 byte 1 byte 0 byte 7 byte 6 byte 5 byte 4 - - - 2 long words are read - 3) ADD = 10, NO = 1 11 10 01 00 - byte 0 - - - - - - - - - - 1 long word is read! For example (Motorola-mode): 1) ADD = 01, NO = 8 11 - 10 01 00 byte 0 byte 1 byte 2 byte 3 byte 4 byte 5 byte 6 byte 7 - - 3 long words are read - 2) ADD = 00, NO = 8 11 10 01 00 byte 0 byte 1 byte 2 byte 3 byte 4 byte 5 byte 6 byte 7 2 long words are read 3) ADD = 10, NO = 1 11 - User's Manual 10 - 01 byte 0 166 00 - 1 long word is read! 01.2000 PEB 20320 Detailed Register Description Next Transmit Descriptor Pointer: This 32-bit pointer contains the start address of the next transmit descriptor. After sending the indicated number of data bytes, MUNICH32 branches to the next transmit descriptor to continue transmission. The transmit descriptor is read entirely at the beginning of transmission and stored in an on-chip memory. Therefore all information in the next descriptor must be valid when MUNICH32 branches to this descriptor when HOLD = 0. For HOLD = 1 the next transmit descriptor pointer is polled together with HOLD; the next transmit descriptor must be valid, when HOLD = 0 is polled. This pointer is not used if a transmit jump, fast transmit abort or transmit initialization channel command is detected while the MUNICH32 still reads data from the current transmit descriptor or polls the HOLD bit. In this case FTDA is used as a pointer for the next transmit descriptor to be branched to. User's Manual 167 01.2000 PEB 20320 Detailed Register Description 4.4 Receive Descriptor 31 30 29 28 27 26 25 24 23 22 0 HOLD HI NO FE C 0 BNO 21 20 19 18 17 16 5 4 3 2 1 0 Receive Data Pointer Next Receive Descriptor Pointer 15 14 13 0 0 0 12 11 10 9 8 0 0 0 0 0 Status 7 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Receive Data Pointer Next Receive Descriptor Pointer The receive descriptor contains 4 long words; the first, third and fourth have to be written by the CPU, the second is written by the MUNICH32 when it branches to the next receive descriptor or when it starts polling the HOLD bit. Note: The MUNICH32 branches to a next descriptor without writing the second long word if the receive initialization command is used during normal operation (see Chapter 4.2.4) HOLD: Setting the HOLD bit by the host prevents the device from branching to the next descriptor. The current data section is still filled. - Afterwards the second descriptor long word is written by the MUNICH32. For HDLC, TMB, TMR the FE and C-bit is set. If the frame could not completely be stored into the data section the RA bit is set in the status. An interrupt with set FI bit is generated, and in case the frame was aborted, the ERR bit is also set. For TMA, V.110/X.30 the C-bit and the RA bit is set and an interrupt with set ERR but with FI = 0 is generated. - Afterwards the device starts polling the HOLD bit, received data, and received events normally leading to interrupts (with RT = 1) are discarded until HOLD = 0 is polled. Each 1 ... 4 byte data word or interrupt event normally leading to an access now results in a poll cycle. Whenever HOLD = 1 is polled the next receive descriptor address is read but ignored. - When HOLD = 0 is polled * for HDLC, TMB, TMR the device continues to discard data until the end of a received frame or an event leading to an interrupt (with RT = 1) is User's Manual 168 01.2000 PEB 20320 Detailed Register Description detected. Afterwards the next received frame is transferred into the next receive descriptor. Interrupts are also generated again. * For V.110/X.30, TMA the device puts the next data into the next receive descriptor. Interrupts are also generated again. The HOLD condition is also discarded upon detection of a receive jump, fast receive abort or receive initialization command. The MUNICH32 then branches to the receive descriptor determined by FRDA even though the HOLD bit in the current receive descriptor may still be `1'. HI: Host initiated interrupt; if the HI bit is set, MUNICH32 generates an interrupt with set HI bit after receiving all data bytes. NO: This byte number defines the size of the receive data section allocated by the host. Because MUNICH32 always writes long words the number of bytes (data section size) must be a multiple of 4 and greater or equal to 4. The maximum data section size is 8188 bytes. After reception of an HDLC frame with a data byte number not divisible by 4 MUNICH32 first transfers the greatest entire ([number of data bytes/4]) in long words. Then the remainder of the data bytes is transferred in another long word, where the non-significant bytes are filled with random values. They should not be interpreted. For example a HDLC frame with one data byte is received: Receive Descriptor Receive Data Section 00000000.00001000.00000000.00000 XX.XX.XX.data 11000000.00000001.Status.00000000 receive data pointer next receive descriptor pointer The data bytes are stored into the receive data section according to the Little Endian convention (Intel mode) or Big Endian convention (Motorola mode). FE: Frame End: The frame end bit is `1' only in HDLC, TMB, TMR mode and indicates that a receive frame has ended in this receive descriptor. For TMA, V.110/X.30 the bit is always `0'. FE = 0 in HDLC, TME, TMR mode means that frame continues in the next receive descriptor or that it filled the current receive data section exactly (BNO = NO). In this case the next receive descriptor will have FE = 1, C = 1, BNO = 0 and no data bytes are stored in the corresponding data section. C: This bit is set by MUNICH32 if * it completes filling the data section normally (BNO = NO) FE = 0, status = 00 * it was aborted by a fast receive abort channel command status = 02 User's Manual 169 01.2000 PEB 20320 Detailed Register Description * for HDLC, TMB, TMR if the end of a frame was stored in the receive data section FE = 1, status gives the receive status determined by RD (interrupt with set FI bit is generated) * for V.110/X.30 mode if the 3 contiguous frames with errors in the synchronization pattern are received FE = 0, status = 20 or status = 21 interrupt with set ERR bit * for V.110/X.30 mode if the data could not be transferred to the shared memory due to RB buffer inaccessibility FE = 0, status = 01 or status = 21 interrupt with set ERR bit. C indicates that the second long word of the receive descriptor was written by the MUNICH32. Afterwards the MUNICH32 writes the next receive descriptor address into CCS. Then it branches to this descriptor immediately. BNO: MUNICH32 writes the number of data bytes it has stored in the current data section into BNO. Status: The MUNICH32 writes the status information into the status byte whenever it sets the C-bit. If the status information is not 00 or 40 an interrupt with ERR bit set is generated. The status is then a means to locate or analyze the receive error. The following table gives a general overview over the different status bits in relation to the channel modes. 7 6 5 4 3 2 1 0 0 SF LOSS CRCO NOB LFD RA ROF HDLC CS = 0 0 NI 0 ILN IL I I I HDLC CS = 1 0 0 0 ILN IL I I I V.110/X.30 0 0 I 0 0 0 IF I TMB 0 0 0 0 IL I IF I TMR 0 0 0 0 IL I IF I TMA 0 0 0 0 0 0 IF 0 Where `0' means that in the corresponding mode the bit is always `0'. It should not be interpreted though to be upward compatible to future versions. User's Manual 170 01.2000 PEB 20320 Detailed Register Description NI means the bit may be `1' or `0' but does not cause an interrupt with set ERR bit. ILN means that it may be `1' or `0' but should not be evaluated if LFD or NOB is also `1'. IL means that it may be `1' or `0' but should not be evaluated if LFD = 1. I means that it may `1' or `0'. IF means that it may be `1' only after a fast receive abort channel command or detection of a HOLD bit in the current receive descriptor. I, IF, IL, ILN lead to an interrupt with ERR bit set. Note: For HDLC, TMB, TMR the status word is only valid if the FE bit is set. The meaning of the individual status bits is as follows: SF = 1 (HDLC mode with CS = 0 only): The device has received a frame with 32 bit between start flag and end flag or end abort flag for CRC16 48 bit between start flag and end flag or end abort flag for CRC32 i.e. BNO was 1 or 2. LOSS = 1 Three contiguous frames with errors in the synchronization pattern were detected. CRCO = 1 A frame with a CRC error was detected CRCO = 0 means the frame had no CRC error. NOB = 1 A frame whose bit content was not divisible by 8 was detected. NOB = 0 means that the frame content was divisible by 8. LFD = 1 Long frame detected. If this bit is set a frame whose bit content was > MFL was detected and aborted. The reception will be continued as soon as a flag is recognized. RA = 1 Receive Abort; this bit indicates that for HDLC: the frame was ended by an abort flag (7FH) or by a receive abort command or a fast receive channel command or by a HOLD bit in the current receive descriptor. for V.110/X.30, TMB, TMR, TMA that the frame or data were aborted by a fast receive abort channel command or a HOLD bit set in the current receive descriptor. ROF = 1 An overflow of the internal buffer RB has occurred and lead to a loss of data. Note: If ROF without FO interrupt is generated for a channel * for HDLC, TMB, TMR only the last part of one frame has been lost. * For V.110/X.30 only data but no status information (change E-, S-, X-bits, Loss) has been lost. User's Manual 171 01.2000 PEB 20320 Detailed Register Description Note: In case of multiple errors all relevant bits are set. In case of ROF = 1 only the error conditions of the frame within which the overflow occurred are reported. Later frames that are aborted do not change the status. Receive Data Pointer: This 32-bit pointer contains the start address of the receive data section. Receive Descriptor Pointer: This 32-bit pointer contains the start of the next receive descriptor. It is not used if a receive jump, fast receive abort or receive initialize command is detected while the MUNICH32 still writes data into the current receive descriptor or polls the HOLD bit. In this case FRDA is used as a pointer for the next receive descriptor to be branched to. User's Manual 172 01.2000 PEB 20320 Application Notes 5 Application Notes 5.1 Test Loops 5.1.1 Test Loop Definitions for the MUNICH32 Two basic types of test loops are provided by the MUNICH32, internal and external. Each of these types is further subdivided into channelwise and complete test loops thus providing four possible test loops. 5.1.1.1 Internal Complete Test Loop The serial data output is physically routed to the serial data input. The TX data appears on the TDATA output pin and the RDATA input pin is ignored. TCLK and RCLK have to be identical; TSP and RSP have to be identical. The logical Transmit and Receive channels have to be programmed identically. CD 1 & RDATA RSP RCLK P Interface TSP TCLK Enable Int. Complete Loop & TDATA ITS08198 Figure 81 User's Manual 173 01.2000 PEB 20320 Application Notes 5.1.1.2 Internal Channelwise Test Loop One (and only one) logical channel is mirrored from the serial data output to the serial data input. The other logical channels are not affected by this operation. The transmit and receive data rates for this single logical channel must be identical. Normal TCLK, RCLK, TSP and RSP design rules apply. This test loop provides channelwise testing capabilities during idle channel time slots, without interfering with normal data transmission/reception. CD 1 P Interface Channel X only RDATA & Enable Int. Channelwise Loop for Channel X TDATA ITS08199 Figure 82 5.1.1.3 External Complete Test Loop The serial data input is physically routed to the serial data output. Data is received on the RDATA pin and routed to the TDATA pin. The received data can be stored in shared memory for additional diagnostic purposes. TCLK and RCLK have to be identical; TSP and RSP have to be identical. User's Manual 174 01.2000 PEB 20320 Application Notes CD RDATA & RSP RCLK Enable Ext. Complete Loop P Interface TSP TCLK & 1 TDATA ITS08200 Figure 83 5.1.1.4 External Channelwise Test Loop One (and only one) logical channel is mirrored from the serial data input to the serial data output. The other logical channels are not affected by this operation. The receive and transmit data rates for this single logical channel must be identical. Normal TCLK, RCLK, TSP and RSP design rules apply. This test loop provides channelwise testing capabilities during idle channel time slots, without interfering with normal data reception/ transmission. CD RDATA Channel X only P Interface Enable Ext. Channelwise Loop for Channel X & 1 TDATA ITS08201 Figure 84 User's Manual 175 01.2000 PEB 20320 Application Notes 5.1.2 Test Loop Activation All of the test loops are closed (activated) and opened (deactivated) by setting/resetting the appropriate combination of bits in the Action Specification (Table 10). Any unlisted combination of LOC, LOOP and LOOPI is an invalid operation. Although the data sheet (Data Sheet 08.93) specifically states that loops must be left (opened) by issuing the reset pin to `1', there are exceptions to this rule. Generally, the test loops can be opened by software. There are several cases that must be examined and these will be discussed in the next section. When closing (activating) a test loop, the IN, ICO, IM, RES, and IA bits should equal `0' and PCM and MFL should be set to the appropriate values. Table 10 Test Loop Activation Test Loop LOC LOOP LOOPI ASP Internal complete 0 0 1 xxxxxx08H Internal channelwise 1 0 1 xxxxxx28H External complete 0 1 0 xxxxxx10H External channelwise 1 1 0 xxxxxx30H No loop 0 0 0 xxxxxx00H The following recommended procedure for activating a test loop assumes that the MUNICH32 has been fully initialized and the user desires to activate a test loop on channel x: * Initialize Rc and Tx channel as appropriate for type of test loop. * Close (activate) the test loop. * Perform test functions (transmit/receive data, check for interrupts, errors, etc.) * Open (deactivate) the test loop. * Perform Rc and Tx off function. Note: While the test loop is activated, do not execute the transmit off command. It will not have the effect of resetting the transmit formatter. 5.1.3 Test Loop Deactivation and Switching As mentioned previously, a test loop can be opened (deactivated) by software. To deactivate a test loop a new ASP should be issued with LOC, LOOP, and LOOPI = 0 and all other bits should be set to the previous values used during activation. Listed below are the possible test loop operations that can be activated with software and those requiring a hardware reset. Table 11 is provided as a graphical representation of this information. User's Manual 176 01.2000 PEB 20320 Application Notes 5.1.3.1 Software Operations Close and open internal complete loop. Close and open internal channelwise loop. Close and open external complete loop. Close and open external channelwise loop. Change from internal complete loop to internal channelwise loop. Change from external complete loop to external channelwise loop. 5.1.3.2 Hardware Reset Operations Change between the internal complete loop and external complete loop. Change between the internal channelwise loop and external channelwise loop. Change between the internal channelwise loop and internal complete loop. Change between the external channelwise loop and external complete loop. Change between internal channelwise loop and external complete loop. Change between internal complete loop and external channelwise loop. Change between external channelwise loop and internal complete loop. Change between external complete loop and internal channelwise loop. Table 11 Allowed Operations Change to Internal Complete Loop Internal Complete Loop Internal Channelwise Loop X HDW Reset required Internal Channelwise Loop External Complete Loop External Channelwise Loop SFW HDW Reset required HDW Reset required HDW Reset required HDW Reset required X External HDW Reset Complete Loop required HDW Reset required External Channelwise Loop HDW Reset required User's Manual HDW Reset required 177 X HDW Reset required SFW X 01.2000 PEB 20320 Application Notes 5.1.4 Test Loop Examples 5.1.4.1 Internal Channelwise Test Loop Generate HW RESET, and hold off RSP/TSP for 1000 SCLK cycles. ASP: A104-8004 ;CEPT, MFL=260, IN, IA=1 IQS: ICQ 0000-001F TSA[0]: 00FF-00FF ;TS0 = CH0 TSA[1...31]: 0000-0000 (x31) CSP[0]: 00E9-0006 ;Tx/Rc init, poll Tx Desc, HDLC FRDA FTDA 0000-0002 ;ITBS = 2 long words CSP[1...31] 0000-0000 0000-0000 0000-0000 0000-0000 (x31) CRA[0...31] 0000-0000 (x32) CTA[0...31] 0000-0000 (x32) ICQ: 0000-0000 (x512) FRDA: 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 32 byte data block 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 32 byte data block 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 32 byte data block + + + + + + FTDA: + + + + User's Manual 4020-0000 0000-0000 RcvDtaPtr 0000-0000 ;HOLD = 1 32 byte data block ; HOLD, FE = 1 for dummy frame 0020-0000 XmtDtaPtr NxtTDPtr abcdefghijklmnop qrstuvwxyz012345 C020-0000 XmtDtaPtr 0000-0000 C000-0000 XmtDtaPtr NxtTDPtr 178 ;FE, HOLD = 1 ABCDEFGHIJKLMNOP QRSTUVWXYZ987654 01.2000 PEB 20320 Application Notes Generate AR Pulse and wait for INT signal (set up TS0 and CH0). Read interrupt queue: ICQ: 9000-8000 ;Action Request Acknowledge ;V2.2 (V2.1 = 8800-8000) ;Polls HOLD bit of 1st Tx Desc. 9000-1000 Set ASP for Internal Channelwise Loop test ASP: A104-0028 ;CEPT, MFL=260, Int. Chnl loop Generate AR Pulse and wait for INT signal. Read interrupt queue: ICQ: 9000-8000 9000-1000 9000-082020 ;Action Request Acknowledge ;Polls HOLD bit of 1st Tx Desc. ;Rc ITF state change Clear HOLD bit in FTDA (allow frame to Tx over Internal Chnl. Loop). Read interrupt queue: ICQ: 9000-1000 ;End of Tx frame, polling HOLD bit of Tx desc. ;Rc frame complete 9000-1020 Read receive descriptors: FRDA: 0020-0000 4020-0000 RcvDtaPtr + NxtRDPtr + 0020-0000 4020-0000 RcvDtaPtr + NxtRDPtr + 0020-0000 C000-0000 RcvDtaPtr + + User's Manual ;C = 1, NO = BNO abcdefghijklmnop qrstuvwxyz012345 ;C = 1, NO=BNO ABCDEFGHIJKLMNOP QRSTUVWXYZ987654 ;FE, C = 1, BNO = 0 ;empty! (p. 139 User's Manual FE description) NxtRDPtr 4020-0000 0000-0000 RcvDtaPtr 0000-0000 179 32 byte data block 01.2000 PEB 20320 Application Notes 5.1.4.2 External Channelwise Test Loop Generate HW RESET, and hold off RSP/TSP for 1000 SCLK cycles. ASP: IQS: TSA[0]: TSA[1...31]: CSP[0]: CSP[1...31] CRA[0...31] CTA[0...31] A104-8004 ICQ 0000-001F 00FF-00FF 0000-0000 (x31) 00E9-0006 FRDA FTDA 0000-0002 0000-0000 0000-0000 0000-0000 (x32) 0000-0000 (x32) ;CEPT, MFL=260, IN, IA=1 ;TS0 = CH0 ;Tx/Rc init, poll Tx desc., HDLC ;ITBS = 2 long words 0000-0000 0000-0000 (x31) ICQ: 0000-0000 (x512) FRDA: 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr + + + + + + FTDA: User's Manual + + 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 4020-0000 0000-0000 RcvDtaPtr 0000-0000 32 byte data block 32 byte data block 32 byte data block ;HOLD = 1 C000-0000 XmtDtaPtr NxtTDPtr 32 byte data block ;HOLD, FE = 1 for dummy frame 180 01.2000 PEB 20320 Application Notes Generate AR Pulse and wait for INT signal (set up TS0 and CH0). Read interrupt queue: ICQ: 9000-8000 ;Action Request Acknowledge ;V2.2 (V2.1 = 8800-8000) ;Polls HOLD bit of 1st Tx Desc. ;FI Frame indication for the 1st Tx Desc. ;Now M32 starts polling HOLD bit of 1st Desc. 9000-1000 9000-1000 Set ASP for External Channelwise test loop ASP: A104-0030 ;CEPT, MFL=260, Ext. Chnl loop Generate AR Pulse and wait for INT signal. Read interrupt queue: ICQ: 9000-8000 9000-0820 ;Action Request Acknowledge ;Only if other station uses idle code 7E ;Received frame complete 9000-1020 Read receive descriptors: ;assumes 64 byte frame externally looped FRDA: 0020-0000 ;with proper HDLC framing 4020-0000 ;NO = BNO RcvDtaPtr abcdefghijklmnop + NxtRDPtr qrstuvwxyz012345 + 0020-0000 4020-0000 ;NO=BNO RcvDtaPtr ABCDEFGHIJKLMNOP + NxtRDPtr QRSTUVWXYZ987654 + 0020-0000 C000-0000 ;FE, C = 1, BNO = 0 RcvDtaPtr ;empty! + NxtRDPtr + 4020-0000 0000-0000 RcvDtaPtr 32 byte 0000-0000 data block User's Manual 181 01.2000 PEB 20320 Application Notes 5.2 MUNICH32 in a LAN/WAN Router 5.2.1 Introduction Subject of this application note is an ISDN/LAN Router, a communication system that enables two LANs to communicate via the ISDN. LAN Router ISDN Router LAN ITS08283 Figure 85 ISDN/LAN Router The structure of the whole system is shown in Figure 85. The router itself is realized as a stand alone solution. It is connected to a standard PC for software download and maintenance control only. After the download the system works fully independent of the host PC. The hardware of the ISDN/LAN router consists of an application specific part and a processor system. The application specific hardware is mainly based on the SIEMENS Component MUNICH32 (Multi Channel Network Interface Controller for HDLC) and a standard LAN controller. Both devices are integrated in the same processor system. The software of the ISDN/LAN router is formed by integrating the MUNICH32 Device Driver Module (DDM) and the corresponding LAN controller Device Driver Module in a Device Driver System (DDS). The device driver modules build a platform to implement the routing strategy in a separate application module. The application specific hardware, the MUNICH32 Device Driver Module and the application module are the main aspects described in the following chapters. The structure of the processor system is briefly illustrated. The DDS service routines are explained as far as necessary to understand this special application. It is suggested that the reader has some knowledge about the MUNICH32 before reading this application note. Detailed information about the MUNICH32, its features and memory structures are given in the MUNICH32 PEB20320 Data Sheet. User's Manual 182 01.2000 PEB 20320 Application Notes 5.2.2 Hardware The processor system is based on a Motorola 68040 processor. It contains 512 KByte SRAM, a bus controller and peripherals like timer, EPROM and interrupt controller. The application specific hardware is integrated by using a Peripheral Connector and an Alternate Busmaster Connector. The Peripheral Connector allows the integration of external peripherals. The Alternate Busmaster Connector is used to connect external bus masters to the local bus. The system is provided with a RS232 serial interface to download executable software on the board. ISDN Interface LAN Interface RS232 Timer EPROM MC68040 Interrupt Controller SRAM Bus Controller Alternate Busmaster Connector Peripheral Connector Glue Logic i82596 MUNICH32 i82C501 ACFA EM 2 PRACT LAN Connector ISDN Connector ITB08284 Figure 86 Hardware Block Diagram User's Manual 183 01.2000 PEB 20320 Application Notes Application Specific Hardware The application specific hardware consists of an ISDN primary rate interface and an Ethernet interface. The MUNICH32 PEB 20320 in conjunction with the layer 1 SIEMENS components ACFA (Advanced CMOS Frame Aligner) PEB 2035 and PRACT (Primary Rate Access Clock Generator and Transceiver) PEB 22320 are used to build the primary rate interface. Incoming data from the ISDN is first processed from the PRACT. It translates the HDB3 coded line signals in dual rail signals. The PRACT also supplies ACFA and MUNICH32 with clock signals. Main task of the ACFA is the frame alignment. Besides, the ACFA translates the dual rail data in a single rail, unipolar bit stream which can be processed by the MUNICH32. The MUNICH32 handles up to 32 channels of a full duplex PCM highway. All time-slots may have data rates between 8 Kbit/s and 64 Kbit/s. The MUNICH32 supports besides other protocols the HDLC formatting/deformatting. If programmed for HDLC mode, the MUNICH32 performs HDLC specific functions like framing, CRC check/generation, flag stuffing and zero bit insertion/deletion autonomously. An on-chip 64-channel DMA controller allows the device to store/read data into/from the SRAM. The DMA controller manages long word or word transfers via a 32-bit processor interface. The P interface can be configured to be Motorola 68020 or intel 80386 compatible. Dual Rail Unipolar Signals PCM Highway P Interface Overvoltage Line IN MUNICH32 ACFA PRACT Line OUT ITS08285 Figure 87 ISDN Interface The Ethemet interface is built with a LAN controller, a Manchester encoder/decoder and a transceiver. The LAN controller supports all IEEE 802.3 standards. The Ethernet framing: preamble generation, source address generation, destination address checking, short-frame detection, automatic length field handling is performed. After LAN controller processing the transmit data is Manchester encoded and forwarded to the transmission line, while receive data is Manchester decoded before being processed by the LAN controller. User's Manual 184 01.2000 PEB 20320 Application Notes System Architecture The system architecture is shown in Figure 88. The MUNICH32, the CPU and the LAN controller store data in the shared memory. The communication between CPU and alternate bus master is done via the shared memory. The CPU informs the alternate bus masters with help of control signals about changes in the shared memory and vice versa. The MUNICH32 input control signal is the Action Request pulse (ACTION REQUEST). It is generated by one CPU write cycle to a defined address and decoding the address lines. The MUNICH32 then responds by generating an interrupt pulse and writing the respective interrupt information in the SRAM. Control Signals MUNICH32 Control Signals CPU i82596 Shared Memory Local Bus ITS08286 Figure 88 System Architecture User's Manual 185 01.2000 PEB 20320 Application Notes Bus Arbitration Since three devices are using the bus it is necessary to implement a bus arbitration. Each bus master requests bus mastership and awaits bus control given to it by the arbiter. The bus arbitration protocol is also Motorola specific. The intel specific signals of the LAN controller (i82596) are translated into Motorola specific signals. The bus arbitration is realized in two devices GAL16V8 (15 ns), both containing a Finite State Machine. Arbiter 1 gives bus mastership to the CPU whenever no other bus master requests bus mastership. If either the MUNICH32 or the LAN controller requests bus mastership the arbiter 2 gives a bus request to the arbiter 1. Arbiter 1 forces the CPU to release the bus and gives bus mastership to arbiter 2. Arbiter 2 then responds to MUNICH32 or LAN controller. In this solution the priority of the MUNICH32 is higher than that of the LAN controller. Consequently if both alternate bus masters request bus mastership at the same time, bus mastership will be given to the MUNICH32. The LAN controller has to wait until MUNICH32 has finished his accesses and arbiter 1 returns the bus to the CPU. It might happen, that some Ethernet frames get lost, because the LAN controller can not get access to the bus in time, but the loss of incoming data from the ISDN (where fees have to be paid) is minimized. Arbiter 2 Arbiter 1 MUNICH32 CPU i82596 ITS08287 Figure 89 Bus Arbitration User's Manual 186 01.2000 PEB 20320 Application Notes Bus Timing Adaptation1) The bus controller manages memory accesses of all bus masters (CPU, MUNICH32 or LAN controller). The bus controller timing is Motorola 68040 specific. The MUNICH32 bus interface is either Intel specific or Motorola 68020/030 specific. Therefore the MUNICH32 bus timing needs to be adapted by using simple glue logic. One Gate Array Logic (Gal16V8, 15 ns) contains all necessary logic. The MUNICH32 Address Strobe (AS) signal determines valid addresses on the bus. The equivalent Motorola 68040 control signal is the Transfer Start (TS). During MUNICH32 write cycles valid data on the bus is indicated with the Data Strobe (DS) signal. MUNICH32 write and read bus cycles are terminated with the Data Transfer Acknowledge (DSACK) signal. For the Motorola 68040 the end of a bus cycle is indicated by the Transfer Acknowledge (TA) signal. During MUNICH32 bus cycles the MUNICH32 output signal AS is used to generate the bus controller input signal TS. The TS is deasserted with the MUNICH32 input DSACK rising edge. Since all bus cycles have the same length the DSACK signal is generated two bus clock cycles after AS is detected low. TS is tristated, if the MUNICH32 is not busmaster. This signal is driven by another bus master during that time. BCLK SCLK TS TA Addr Data AS DSACK ITD08288 Figure 90 MUNICH32 Timing Adaption 1) See also Chapter 5.2.6. User's Manual 187 01.2000 PEB 20320 Application Notes The LAN controller's (i82596) bus timing also needs to be adapted. The address lines A1, AO, Size 0 and Size 1 need to be generated, because the LAN controller performs 8 bit and 16 bit cycles as well as 32 bit cycles. There are also some non standard bus signals for the LAN controller, that have to be generated. Furthermore the System Clock and the Bus Clock have to be synchronized. All necessary glue logic for the LAN controller is realized in four devices Gal 16V8. 5.2.3 Software The software is based on a message oriented device driver system. The device driver modules and application modules have a structure that allows to access them via defined entry points. Module Entry Points Two Entry points offer access to the DDMs. Messages can be sent to the DDM via the Message Entry Point. A hardware interrupt causes the program to branch to the Interrupt Entry Point. The APM also offers access via a Message Entry Point, but since the APM does not control any hardware, there does not exist any Interrupt Entry Point. Device Driver System Message Message Device Driver Module Application Module Interrupt Hardware ITS08289 Figure 91 Module Entry Points User's Manual 188 01.2000 PEB 20320 Application Notes DDS Tasks The message transfer between the modules is the main task of the DDS, realized by some service routines. DDMs and APMs are integrated in the DDS by executing a Module Init Routine. The Module Init Routine is called by the DDS. Additionally the DDS offers service routines for memory management. All service routines can be used by all modules. Some memory management functions will be presented in more detail. For detailed information about the other DDS service routines please refer to the SIPB 7520 Primary Rate User Board or EASY532 Datacom Userboard Documentation. Memory Management With the memory management functions the allocation of message descriptors, MUNICH32 receive/transmit descriptors1) or LAN controller receive/transmit descriptors is simplified. During initialization of the memory management module DDSM a pool of descriptors is prepared in a linked list. The memory management functions allow to allocate descriptors and to free descriptors. During initialization of the memory management module DDSM a pool of descriptors is prepared in a linked list. The memory management functions allow to allocate descriptors and to free descriptors. During allocation a descriptor is taken from the prepared list. After utilization the descriptor is given back to the descriptor pool. There is one pool for message descriptors and one pool for MUNICH32 receive/transmit and LAN controller receive/transmit descriptors. Because MUNICH32 transmit and receive descriptors differ and they both differ from the LAN controller transmit and receive descriptors, there are service functions available to convert the descriptor type. 1) Refer to MUNICH32 Data Sheet. User's Manual 189 01.2000 PEB 20320 Application Notes Message Descriptor Pool Allocate Free MUNICH32/LAN Controller Descriptor Pool Convert Allocate Free ITS08290 Figure 92 Memory Management User's Manual 190 01.2000 PEB 20320 Application Notes 5.2.3.1 Device Driver Module MUNICH32 Tasks The MUNICH32 Device Driver Module has to prepare all memory structures for the MUNICH32. The ACTION REQUEST Pulse has to be generated. The device driver module also has to treat the MUNICH32 interrupts. Message Entry Point Every incoming message results in executing a function. Function Action ResetMunich32 Action Specification Reset bit is set, All channels are initialized, all time-slots are initialized, ACTION REQUEST Pulse is generated. ConfigMunich32 Sets PCM mode and maximum frame length, ACTION REQUEST Pulse is generated. InitlnterruptQueue Interrupt Attention bit is set, A new interrupt queue is defined, ACTION REQUEST Pulse is generated. InitChannel Action Specification in-bit is set, Initializes receiver and transmitter of selected channel, ACTION REQUEST Pulse is generated. InitTxChannel Initializes transmitter of selected channel, ACTION REQUEST Pulse is generated. InitRcChannel Initializes receiver of selected channel, ACTION REQUEST Pulse is generated. SendFrame Adds tx descriptors to the transmit descriptor queue and clears hoId bit of poll descriptor if the channel is active. TxJump If no poll descriptor is detected Initialize Channel Only bit is set, `transmit jump' command is given, if the previous command was not `receive abort' or `off the receive clear' command is given, ACTION REQUEST Pulse is generated. TxHold Initialize Channel Only bit is set, turns channel on or off, turn channel on: if last command was `transmit off' or `transmit abort' `transmit clear' is given and `transmit hold' bit is cleared, turn channel off: if channel is active and `transmit hold' bit is set, ACTION REQUEST Pulse is generated. User's Manual 191 01.2000 PEB 20320 Application Notes Function Action TxShutDown Initialize Channel Only bit is set, gives `transmit off' command or `transmit abort' command, ACTION REQUEST Pulse is generated. RcJump Initialize Channel Only bit is set, If last command was `transmit off' or `transmit abort' `transmit clear' is given, `receive jump' command is given, ACTION REQUEST Pulse is generated. RcShutDown `Initialize Channel Only' bit is set, Gives receive off command if receiver was aborted otherwise gives receive abort command, ACTION REQUEST Pulse is generated. SwitchlnternalChanLoop Sets/clears Internal Channelwise Loop, ACTION REQUEST Pulse is generated. SwitchlnternalCompLoop Sets/clears Complete Loop, ACTION REQUEST Pulse is generated. ShowMunich32VersionNr ACTION REQUEST Pulse is generated. CheckActionRequestQueue Looks for messages to be processed and branches to the Message Entry Point. Interrupt Entry Point The information in the interrupt queue is read and a message containing that information is sent to the user. In case of a received frame the written receive descriptors are linked to a message and sent to the user. The next available descriptor in the list is linked to the memory structures. An equivalent number of new receive descriptors is allocated and linked to the end of the receive descriptor queue. In case of a transmit acknowledge interrupt the used transmit descriptors are released to the descriptor pool. User's Manual 192 01.2000 PEB 20320 Application Notes Programming the MUNICH32 for this Application The basic programming of the MUNICH32 for this application is realized in the Module Initialization Routine. Further programming is done by calling the function `Init Channel' for each channel once. Transmit data is then added to the memory structures by passing a message with linked transmit descriptor(s) to the function `Send Frame'. Module Initialization Routine Here the IM-bit is cleared because the MUNICH32 DDM expects the action request acknowledge interrupt. The values for PCM and MFL are set. The PCM format is a 32channel format according to CEPT. The maximum frame length is set to its maximum. Finally the address and length of a new interrupt queue are defined. Those values will not be changed anymore. Init Channel Routine The function `Init Channel' initializes the time-slot assignment and the channel specification for one channel. The channel number is set to the value of the variable `channel'. The MUNICH32 is alerted to access all time-slot assignments and the channel specification by setting the in-bit. The fillmask (transmit and receive) for the selected channel is written in the appropriate word of the time-slot assignment. All other channels and their fillmasks are not affected. For this application all interrupts are enabled. Initialization of the selected channel comprises the definition of a new ITBS value and initialization of the receiver and the transmitter. The transmit hold bit is cleared. After initialization the MUNICH32 starts polling the hold bit of the current transmit descriptor. Therefore a transmit descriptor is allocated and connected to the memory structures. Its hold bit and fe-bit are set to one, its no-bits are set to zero. For that reason the MUNICH32 does not transmit anything but polls this descriptor. Since after the receiver's initialization the MUNICH32 is ready to receive data, a queue of receive descriptors is allocated and linked to the memory structures. The hold bit of the last descriptor in the list is set to indicate the end of the list. In all other descriptors the hold bit is cleared. User's Manual 193 01.2000 PEB 20320 Application Notes Send Frame Routine Calling `SendFrame' after initialization of a channel results in executing `AddHdlcFrame'. In that routine the transmit descriptors are disconnected from the message and linked to the memory structures. If the message source is the `MROUTE Application Module' the hold bit and fe-bit indicating the end of a frame and the end of the list have already been set/cleared in the MROUTE module, they are not modified anymore. If the message source is any other module the fe-bit and hold bit are cleared in all descriptors except for the last one. There the hold bit has to be set, to prevent the MUNICH32 from branching to the next descriptor. Setting the fe-bit in the last descriptor only forces the MUNICH32 to send the data in one HDLC frame. The bits HI, V110 and CSM are cleared in both cases. Transmit/Receive Interrupt A transmit acknowledge interrupt is treated by returning the transmit descriptor(s) to the descriptor pool. After a receive interrupt (FI bit set) the receive descriptors with c-bit set, are disconnected from the list of receive descriptors, linked to a message and sent to the MROUTE module. The next free receive descriptor in the list is linked to the memory structures. An equivalent number of new descriptors is allocated and linked to the end of the receive descriptor list. 5.2.3.2 Application Module MROUTE The application module MROUTE implements the routing strategy. Routing Strategy Both devices the MUNICH32 and the LAN controller organize receive and transmit data in a linked list of receive descriptors and a linked list of transmit descriptors. The data is stored in data buffers of variable size. The receive/transmit descriptors contain the address of the data buffer. The basic idea behind the routing strategy is, to take the MUNlCH32's receive descriptor and link it to the LAN controller's transmit descriptor queue. On the other hand to take the LAN controller's receive descriptor and link it to the MUNlCH32's transmit descriptor queue. User's Manual 194 01.2000 PEB 20320 Application Notes ISDN 64 kbit/s each Channel LAN max 10 Mbit/s fe = SET Ch1 Frame Descr Count Count EOF = 0 fe = SET 0 Frame Descr Count Count EOF = 1 2 EOF = SET fe = SET 0 Ch 2 Frame Descr Count Count EOF = 1 1 2 1 ITS08291 Figure 93 Insertion of additional Information To make efficient use of the available bandwidth, the parallel use of several B-channels is one of the routing strategy's goals. Every Ethernet frame is divided into several parts because the LAN controller stores the received data in several receive descriptors, if necessary. The frame is then sent via the ISDN by using a separate B-channel for every LAN receive descriptor. To ensure that the parts of the Ethernet frame will be reassembled in correct order, every part of the Ethernet frame is supplied with additional information. That additional information has to be extracted before reassembling the frame. In Figure 93 an example of one Ethernet frame consisting of three descriptors, spread over two B-channels, is shown. The additional information contains the frame number, the descriptor number and the information, whether the frame is completed. To simplify the extraction of the additional information every frame part and its additional information are sent in one HDLC frame. User's Manual 195 01.2000 PEB 20320 Application Notes The fe-bit marks the end of one HDLC frame, the EOF bit marks the end of the Ethernet frame. The additional information comprises the 8-bit word descriptor count, 16-bit word frame count and EOF a 8-bit variable which indicates the last descriptor of the frame. Message Entry Point The message entry point calls two functions: IsdnRouteFrame and LanRouteFrame. An Ethernet frame is processed by IsdnRouteFrame, an ISDN frame by LanRouteFrame. The MUNICH32 receive descriptors are converted to LAN controller transmit descriptors and those of the LAN controller are converted to MUNICH32 transmit descriptors. MROUTE Module LAN Route Frame ISDN Route Frame Message Descr Message Descr LAN Controller TX Descr MUNICH32 RC Descr LAN Controller RC Descr MUNICH32 TX Descr MUNICH32 DDM LAN Controller DDM ITS08292 Figure 94 Message Flow between DDMs and MROUTE Module Besides the IsdnRouteFrame realizes the insertion of additional information and splits an Ethernet frame on several B-channels. The additional information is stored in an extra allocated transmit descriptor which is placed before the descriptor containing the data. Every descriptor and the respective extra descriptor are connected to one message descriptor. This message with set hold bit and set fe-bit in the descriptor containing the data is further processed from the MUNICH32 DDM routine `Send Frame'. LanRouteFrame reassembles the Ethernet frames. It takes into account, that the parts might arrive with different delays. Every complete frame is connected to a message descriptor and than processed from the LAN controller DDM. User's Manual 196 01.2000 PEB 20320 Application Notes 5.2.4 Performance Considerations Some considerations about the performance are made by investigating the maximum data rate. Further investigations are made about the bus occupancy by all busmasters and the MUNICH32 poll access' influence on the data rate. Finally the processing of one frame is illustrated. Data Rates The data rate during transmission from the ISDN into the Ethernet was tested. kbit/s 2000 1800 1600 1400 1200 1000 800 600 400 200 0 Data Rate available Data Rate without MUNICH32 polling Data Rate with MUNICH32 polling Channels 0 3 6 9 12 15 18 21 24 27 30 ITD08293 Figure 95 Data Rate The size of one data buffer is 128 Byte. If the number of channels exceeds 24 the data rate depends on the MUNICH32 transmitter. If the transmitter is initialized the data rate decreases. This shows the influence of the MUNICH32 polling the Hold bit. User's Manual 197 01.2000 PEB 20320 Application Notes Bus Occupancy The bus occupancy during normal operation is shown in Figure 96. In this case the data buffer size was 32 Byte. The CPU has busmastership during 90% of the time. The MUNICH32 as well as the LAN controller, each have busmastership 5% of the time. The bus occupancy of the MUNICH32 is calculated to 2.5%1). In this system it is higher because of inserted wait states in every bus cycle. Another reason is the bus controller's clock which is switched from 33 MHz to 40 MHz. This and the existence of two alternate bus masters results in a more time consuming arbitration protocol than that needed for a simpler architecture. i82596 M32 5 % 5% CPU 90 % ITD08294 Figure 96 Bus Occupancy 1) Compare Data Sheet. User's Manual 198 01.2000 PEB 20320 Application Notes MUNICH32 Polling The influence of the polling can be illustrated by showing the bus occupancy of MUNICH32 poll accesses only. M32 17 % Idle 10 % CPU 73 % ITD08295 Figure 97 Bus Occupancy During Polling Here the MUNICH32 is polling 31 channels (= 31 x 2 read accesses during 125 s). Every access is 5 clock cycles long, instead of the minimum length of 4 clock cycles. The time for the arbitration protocol needed during every access results in bus idle time. User's Manual 199 01.2000 PEB 20320 Application Notes Frame Processing During normal operation the processing of a frame comprises three consecutive parts. During transmission from ISDN to LAN the frame is first processed from the MUNICH32, then from the CPU and finally from the LAN controller. Frame 1 Frame 2 MUNICH32 CPU i82596 t ITD08296 Figure 98 Frame Processing Though the CPU is never idle, its part on frame processing is that between the MUNICH32 and the LAN controller are active. The time to process one frame is the minimum delay required between frames during continuous transmission. User's Manual 200 01.2000 PEB 20320 Application Notes 5.2.5 Final Remarks This application note shows a design example for the MUNICH32 (PEB 20320). Though the design example is of reduced complexity it gives an idea of how to use the MUNICH32 in a system. The MUNICH32 is integrated in a 68040 processor system in conjunction with one more alternate bus master. To achieve higher data rates the time to process the frames should be minimized. This includes minimization of bus idle time. The bus arbitration still has big improvement potential because of its modular structure. Additionally the existence of the alternate bus masters results in clocking the bus controller with two different frequencies. This also results in increased idle time for the bus should therefore be modified. Furthermore frame processing could be shortened by eliminating the wait states in every bus cycle. The influence of MUNICH32 poll accesses is extremely high in this example, because of the bus arbitration architecture and the system architecture with one bus controller for all bus masters. But anyway it should always kept in mind, that the bus occupancy during polling is higher than during transmission. During transmission it decreases rapidly. No upper layer software is realized in this example so far. For `real life' routing layer 2 and 3 software module(s) have to be integrated. User's Manual 201 01.2000 PEB 20320 Application Notes MROUTE Module LAN Route Frame ISDN Route Frame Upper Layer Software Upper Layer Software Message Descr Message Descr LAN Controller TX Descr MUNICH32 RC Descr LAN Controller RC Descr MUNICH32 TX Descr MUNICH32 DDM LAN Controller DDM ITS08297 Figure 99 Integration of Upper Layer Software User's Manual 202 01.2000 PEB 20320 Application Notes 5.2.6 Adaption of the 68040 P Signals begin header This GAL is used to adapt the 68040 -processor signals to the MUNICH32. It is used in a system with a frequency relationship of 1/2 PCLK/SCLK. end header begin definition device gal1 6v8; {Select the device to be Gal16V8} input bclk M32ASQ reset M32BGACKQ int ACREQM68 RWQ clk rclk = 1, = 2, = 3, = 4, = 5, = 6, = 7, = 8, = 9; feedback (com) DSACKQ = 19; output (com) TSQ RESETQ INTQ ACREQM32 sclk = 18, = 17, = 16, = 15, = 14; statebits sb2 sb1 = 13, = 12; state_names idle one two = 2, = 1, = 0; {= musclk} end definition User's Manual 203 01.2000 PEB 20320 Application Notes begin equations TSQ.OE TSQ RESETQ INTQ ACREQM32 sclk = /M32BGACKQ; = /(/M32ASQ x DSACKQ); = /reset; = int; = /(/ACREQM68 x reset x /RWQ); = (/reset x rclk) + (reset x /clk); end equations begin state_diagram tktadaptor (sb2, sb1) state all: if (/reset + M32ASQ) then idle with DSACKQ = 1; endwith; state idle: DSACKQ = 1; if (/M32ASQ x reset) then one else idle; state one: DSACKQ = 1; go to two; state two: DSACKQ = 0; if M32ASQ then idle else two; end state_diagram User's Manual 204 01.2000 PEB 20320 Application Notes 5.2.7 Schematics LAN Interface SER_INT Ctrl BRQ BGACKQ BGQ A D MUBRQ MUBGACKQ MUBGOQ MUBGQ SERINT.SCH LAN_CONT.SCH ISDN MUBGQ MUBGOQ MUBGACKQ MUBRQ Ctrl A D BGQ BGACKQ BRQ EASY320.SCH ITS08298 Figure 100 User's Manual 205 01.2000 PEB 20320 Application Notes ACFA_PRACT MUNICH32 PCLK3 RTCLK TRSP RDATA TDATA PCLK3 CLK2M FSCQ RDO XDI P1 LIN1 FSQ LIN2 LOUT1 LOUT2 JP1 GND 3 1 2 SYNC CLK4M CLK2M XCLK MUNICH32.SCH ACFAPRAC.SCH GND VCC 1 14 2 15 3 16 4 17 5 18 6 19 7 20 8 21 9 22 10 23 11 24 12 25 13 CONNECTOR DB25 Female ITS08299 Figure 101 User's Manual 206 01.2000 PEB 20320 Application Notes J1C J1A 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 A31 A30 A29 A28 A27 A26 A25 A24 A23 A22 A21 A20 A19 A18 A17 A16 A15 A14 A13 A12 A11 A10 A9 A8 A7 A6 A5 A4 A3 A2 U1 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 D31 D30 D29 D28 D27 D26 D25 D24 D23 D22 D21 D20 D19 D18 D17 D16 D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27 A28 A29 A30 A31 VG96 VG96 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 D16 D17 D18 D19 D20 D21 D22 D23 D24 D25 D26 D27 D28 D29 D30 D31 J1B 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 MUSCLK BBQ BCLK TSQ BGQ LOCKQ M32BGQ BGACKQ WRQ PCSQ5 VCC GND JP 2 1 ADDWSQ 2 CRSTQ MUINTQ PCLK3 VG96 100 96 94 91 102 107 109 114 116 120 122 126 128 133 135 139 143 147 149 154 156 160 2 6 8 13 15 19 21 26 28 33 35 39 BE0 BE 1 BE 2 BE 3 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27 A28 A29 A30 A31 95 99 101 106 108 113 115 119 121 125 127 132 134 138 142 146 148 153 155 159 1 5 7 12 14 18 20 25 27 32 34 38 90 85 86 75 76 74 82 79 81 80 66 40 I/M D0 D1 CI 0 D2 CI 1 D3 CI 2 D4 CI 3 D5 CI 4 D6 D7 TEST D8 D9 D10 D11 D12 JTEST 0 D13 JTEST 1 D14 JTEST 2 D15 JTEST 3 D16 D17 RESET D18 SCLK D19 D20 D21 D22 D23 D24 D25 D26 D27 D28 D29 D30 D31 W,R/R,W ADS/AS DS READY/DSACK BERR B16 HOLD/BR HLDA/BG PM HLDAO/BGO AR INT/INT RTCLK TRSP RDATA TDATA PCLK3 M32BGQ U8 GND OE CLK RCLK RSP RDATA TCLK TSP TSP 44 45 46 69 68 67 12 13 14 15 16 17 18 19 M32BGQ 8 7 6 5 4 3 2 1 O8 O7 O6 O5 O4 O3 O2 O1 11 BCLK 9 8 7 6 5 4 3 2 GAL16V8 BGACKQ BRQ LOCKQ BBQ CRSTQ BGACKQ BRQ BGQ RP1 1 2 3 4 5 6 7 8 73 47 48 49 50 51 65 16 15 14 13 12 11 10 9 VCC 4.7 k MUBGACKQ U7 OE CLK GND 12 13 14 15 16 17 18 19 53 54 55 56 60 61 DSACKQ 8 7 6 5 4 3 2 1 O8 O7 O6 O5 O4 O3 O2 O1 GAL16V8 VCC 11 9 8 7 6 5 4 3 2 GND MUSCLK RWQ PCSQ5 INT MUBGACKQ CRSTQ ASQ TSQ MUINTQ R1 MUBRQ 3.3 k MUNICH32 MUBGOQ MUBGQ VCC GND C1 100 nF C2 100 nF C3 100 nF C4 100 nF C5 100 nF C6 100 nF C7 100 nF C8 100 nF C9 100 nF C 10 100 nF C 11 100 nF C 12 100 nF C 13 100 nF C 14 100 nF ITS08300 Figure 102 User's Manual 207 01.2000 PEB 20320 Application Notes ADR3 ADR2 ADR1 ADR0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 J2A VG96 U10 LOOP RSTQ RDO AD0 AD1 AD2 AD4 AD5 VCC D1 LED Red XDI R2 1k 1 VCC 22 33 11 JP 3 GXDI COS U3 PCSQ2 46 CE FRDQ 22 RD FRDQ 25 WR INTQ2 5 AINT 36 ACKNL ADR0 18 A0 ADR1 19 A1 ADR2 20 A2 ADR3 21 A3 27 COS RDO 4 RDO 34 XDI VCC R4 10 k AD0 AD 1 AD 2 AD 3 AD 4 AD 5 AD 6 AD 7 33 8 39 40 6 37 9 10 11 12 13 14 15 16 ROID XOID RSIGM XSIGM RCHPY XCHPY D0 D1 D2 D3 D4 D5 D6 D7 XTOM XTOP XDOM XDOP RDIM RDIP XRCLK RRCLK 3 44 43 42 31 30 41 29 SCLK 28 1 2 3 4 5 6 7 8 19 18 17 16 15 14 13 12 O1 O2 O3 O4 O5 O6 O7 O8 PCSQ2 G0 G1 G2 G4 G5 GXDI G6 1 CLK 11 OE GAL16V8 GND 2 U2A 74HC04 R3 4.7 k 2 3 4 5 6 7 8 9 CLK2MQ XCLK CLK4MQ CLK2M FSC 7 30 31 37 36 38 39 40 4 RFSP 7 SYP 32 32 28 29 RES 35 2 1 3 JP4 D2 1N4148 U2B ACFA 3 R5 1 M C15 47 nF 4 74HC04 R6 1k D3 LED Green GND VCC GND ITS08301 Figure 103 User's Manual 208 01.2000 PEB 20320 Application Notes 2 3 4 5 6 7 8 9 RSTQ PCSQ3 WRQ AD 0 AD 1 AD 2 AD 3 AD 4 PCLK3 O1 O2 O3 O4 O5 O6 O7 O8 19 18 17 16 15 14 13 12 FRDQ VCC 2.2 k XDI RDO SYNC CLK2M CLK2MQ CLK4MQ FSC FSCQ XCLK CLK33_CON LOOP PCLK3 GAL16V8 GND C25 47 F C24 47 nF VCC 35 41 23 22 34 42 19 18 1 VSSD VSSR VSSX VSSX VDDD VDDR VDDX VDDX VDD2 D5 R7 R9 U5 1 XL 1 XL 2 RL 1 RL 2 R8 D6 JATT SYNC MODE LL LR LS 2 LS 1 LS 0 CS XTAL 4 XTAL 3 XTAL 2 XTAL 1 PRACT 5 20 24 44 2 15 k D7 VCC GND GND VCC D8 R 2.2 k C18 12 pF 100 nF R12 VCC LIN1 1k 8 5 1 F5 SO5K130 R13 6 10 ZKB_402/512 F3 A81_C90X 2 1 1k LIN2 F4 A81_C90X D11 2 X1 12 MHz VCC GND C22 10 pF C23 JATT SYNC MODE G4 G5 G2 G1 G0 C21 10 pF R11 60 k R11 60 k D10 F2 A81_C90X 2 GND C19 LOUT2 1 1k GND 43 17 27 3 26 14 11 8 C17 12 pF 6 10 ZKB_402/512 F1 A81_C90X 2 R14 3 U6 1 VCC 1 F6 SO5K130 D9 C26 LOUT1 1k 8 C16 C20 3 15 k 33 9 10 12 13 FSC FSC XDIN XDIP RDON RDOP RCLK CLK2M CLK2M CLK4M CLK4M CLK12M CLK16M XCLK XTIN XTIP VCC GND D4 X2 16 MHz G6 WRQ R15 MODE JATT COS LP U4 6 7 30 31 37 36 38 39 40 4 5 16 15 32 28 29 VCC 1 CLK 11 OE GND CLK2MQ XCLK CLK4MQ CLK2M FSC FSCQ 1 2 3 4 5 6 7 8 GND PCSQ4 PCSQ3 PCSQ2 RSTQ AD7 AD6 AD5 AD 4 AD 3 AD2 AD 1 AD 0 U9 PCSQ2 G0 G1 G2 G4 G5 GXDI G6 INTQ2 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 J2B VG96 J2C VG96 VCC GND GND GND C28 100 nF C29 100 nF C30 100 nF C31 100 nF ITS08302 Figure 104 User's Manual 209 01.2000 PEB 20320 Application Notes U Data U 18 16 14 12 9 7 5 3 CLK33 TSP_OUT PCLK3 TCLK_OUT CLK33_CON 14 15 16 17 18 19 20 21 25 26 27 28 29 30 31 32 35 36 37 38 39 40 41 42 43 46 47 48 50 51 52 53 33 MHz 1 Y1 1 Y2 1 Y3 1 Y4 2 Y1 2 Y2 2 Y3 2 Y4 1A 1 1A 2 1A 3 1A 4 2 A1 2A 2 2A 3 2A 4 2 4 6 8 11 13 15 17 8 PHI OSZI TSP_IN 1G 1 2G 19 74HCT244 TCLK_IN GND D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D 10 D 11 D 12 D 13 D 14 D 15 D 16 D 17 D 18 D 19 D 20 D 21 D 22 D 23 D 24 D 25 D 26 D 27 D 28 D 29 D 30 D 31 124 ADS ADSQ 65 129 130 9 123 118 69 VCC VCC RDTQ HOLD RLDA L_RESET VCC 2.7 k LE/BE BS 16 RDY CLK2 HOLD HLDA RESET 3.3 k GND 125 INT/INT 3 PORT 119 CA MUINTQ PORTQ CA VCC RP1 16 15 14 13 12 11 10 9 RP2 1 2 3 4 5 6 7 8 4.7 k 16 15 14 13 12 11 10 9 RDTQ MU_BGOQ L_LOCKQ CPURSTQ LAN_W_RQ ADSQ GND 82596DX 1 2 3 4 5 6 7 8 2.7 k HOLD BE 0 BE 1 BE 2 BE 3 A2 A3 A4 A5 A6 A7 A8 A9 A 10 A 11 A 12 A 13 A 14 A 15 A 16 A 17 A 18 A 19 A 20 A 21 A 22 A 23 A 24 A 25 A 26 A 27 A 28 A 29 A 30 A 31 W/R LOCK BREQ BE 114 113 112 109 108 107 106 105 104 103 102 101 97 96 95 94 93 92 91 90 87 85 84 83 82 81 80 79 76 74 73 72 71 70 120 126 115 ADDR LAN_W_RQ L_LOCKQ GND LPBK 58 CDT CRS RXD RXC TXD TXC RTS CTS R VCC Resistor 61 63 60 59 54 64 57 62 SER_INT GND 4.7 k 1 GND 9 8 7 6 5 4 3 2 RAPACK ITS08303 Figure 105 User's Manual 210 01.2000 PEB 20320 Application Notes RESET 2 3 4 5 6 7 8 9 MUCLK CPURSTQ 1 2 3 4 5 6 7 8 O1 O2 O3 O4 O5 O6 O7 O8 19 18 17 16 15 14 13 12 Address BE 1 CLK 11 OE GND L_RESET GAL16V8A 2 3 4 5 6 7 8 9 GND MUCLK DTOEQ LAN_CSQ R_WQ M32_ARQ CPURSTQ 1 2 3 4 5 6 7 8 O1 O2 O3 O4 O5 O6 O7 O8 19 18 17 16 15 14 13 12 GND HLDAIN CLK33 1 2 3 4 5 6 7 8 O1 O2 O3 O4 O5 O6 O7 O8 A1 A0 SIZ1 LAN_CSQ M32_CSQ SIZ0 Arbiter 2 MUCLK CPURSTQ Signal ADSQ LAN_W_RQ TAQ 19 18 17 16 15 14 13 12 GAL16V8A 2 3 4 5 6 7 8 9 MU_BRQ HOLD ML_BGQ MU_BGACKQ 19 18 17 16 15 14 13 12 O1 O2 O3 O4 O5 O6 O7 O8 M32_ARQ GAL16V8A 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 1 CLK 11 OE PORTQ CA 1 CLK 11 OE GND BEQ0 BEQ1 BEQ2 BEQ3 ML_BGQ MU_BGACKQ A4 Port CLK33 PCSQ5 2 3 4 5 6 7 8 9 RDYQ R_WQ TSQ CLK33 1 2 3 4 5 6 7 8 O1 O2 O3 O4 O5 O6 O7 O8 19 18 17 16 15 14 13 12 BRQ BGACKQ HLDAIN MU_BGQ 1 CLK 11 OE GND GAL16V8A 1 CLK 11 OE GND ITS08310 GAL16V8A Figure 106 User's Manual 211 01.2000 PEB 20320 Application Notes Data J1C Address J1A J1B 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 VG96 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D 10 D 11 D 12 D 13 D 14 D 15 D 16 D 17 D 18 D 19 D 20 D 21 D 22 D 23 D 24 D 25 D 26 D 27 D 28 D 29 D 30 D 31 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 PCLK3 DTOEQ TAQ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 MUINTQ0 CPURSTQ MUINTQ GND VCC PCSQ5 W_RQ BGACKQ ML_BGQ LOCKQ BGQ_68 TSQ BCLK BBQ MUCLK VG96 VG96 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A 10 A 11 A 12 A 13 A 14 A 15 A 16 A 17 A 18 A 19 A 20 A 21 A 22 A 23 A 24 A 25 A 26 A 27 A 28 A 29 A 30 A 31 ITS08311 Figure 107 User's Manual 212 01.2000 PEB 20320 Application Notes GND R 78 SERINT R 78 R 240 R 240 U TXD TXCQ RTSQ 17 TXD 16 TXC 15 TEN RXD RXCQ CRSQ CDTQ C CAP 9 8 6 7 1 RXD RXC CRS CDT ENETV1 CLSN CLSN RCV RCV TRMT TRMT 2 NOOR 3 LPBK/WDTD LPBKQ 1 2 3 4 5 6 12 11 4 5 19 18 X1 14 X2 13 UA 2 O4 J BNC HBE 16 Y 1 R D 150 LED Yellow GND GND 2 3 GND JP JUMPER3X1 EM2 20 MHz C 30 pF C 0.01 F CDS 20 RXI 18 TXO 17 CD+ CDRX+ RXTX+ TX- VEE 11 DM 12 82C50TAD 1 GND R 1 M U VCC C 30 pF GND U 10 VCC C k105 R 40 k CEXT 11 REXT/CEXT 9 RIN 3 4 5 A1 A2 B Q 6 Q 1 T21 R D 150 LED Green R D 150 LED Red GND U 10 VCC C k105 R 40 k CEXT 11 REXT/CEXT 9 RIN 3 4 5 A1 A2 B Q 6 Q 1 VCC ITS08312 T21 Figure 108 User's Manual 213 01.2000 PEB 20320 Application Notes 5.3 Memory Bus Occupancy for a Single MUNICH32 The MUNICH32 may be used in different system architectures depending mainly on how the data buffers are shared between the interacting bus masters. In the following the memory bus occupancy is calculated for a system, where the MUNICH32 is directly coupled with a 32-bit CPU (compatible to either Motorola 68020 or Intel 386) sharing one common local CPU bus and translated via an appropriate system bus controller sharing the system memory as well. This example system looks very similar to the one depicted in the Figure 7 and Figure 9 of Chapter 1. In this case it is easier to estimate the behavior of the complete system. In addition to that, the following assumptions are made about the communication parameters: - HDLC operating mode - the MUNICH is clocked with SCLK = 16 MHz - the bus arbitration time is estimated to be about 4 extra clock cycles (SCLK) for every 10 MUNICH32 memory accesses (typical is 10 to 16) - the data buffer size allocated in the data buffer pool is 32 bytes for transmit and receive descriptors - a full duplex connection with up to 32 x 64 Kbit/s channels and heavy traffic load (shared flags) - the data size per HDLC frame is defined to be without the shared flag and the two CRC bytes - when the data size exceeds 32 bytes, more than one descriptor is needed for a single frame - an interrupt information is generated for every descriptor. The MUNICH32 needs the following 32-bit memory accesses (read or write): Receive: User's Manual read descriptor write current descriptor address write status write interrupt write data (size) 214 3 1 1 1 accesses size 1 1 1 2 1 3 1 4 2 5 : : 01.2000 PEB 20320 Application Notes Transmit: read descriptor write current descriptor address write interrupt read data (size) 3 1 1 accesses size 1 1 1 2 1 3 1 4 2 5 : : The accumulated access time for a single MUNICH32 channel, depending on the actual frame size, is then related to the serial transfer time on a PCM system: (3 + size) x 125 s. The following two diagrams illustrate the overall results for two different ranges and their corresponding resolution. As you can see, for frame size greater than 32 bytes the time needed for MUNICH32 memory accesses drops below 5%. That means in a simple communication subsystem (e.g. Primary Access Board) the CPU performance is also reduced by 5% only and it is therefore not necessary to use a complex multiport memory approach to reach a significant overall performance gain. Memory Bus Occuppancy 25 Ch=32 Ch=30 Ch= 1 % 20 15 10 5 0 1 32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 512 Number of Data Bytes ITD04696 Figure 109 Frame Size 1 to 512 User's Manual 215 01.2000 PEB 20320 Application Notes Memory Bus Occuppancy 25 Ch=32 Ch=30 Ch= 1 % 20 15 10 5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Number of Data Bytes ITD04697 Figure 110 Frame Size 1 to 32 User's Manual 216 01.2000 PEB 20320 Application Notes 5.3.1 Bus Occupancy Calculations As described in the previous section, the MUNICH32 in a steady state condition consumes approximately 5% of the system bus bandwidth. Based on the conditions previously described, a set of equations can be used to describe the MUNICH32 system bus behavior. Other MUNICH32 systems can be evaluated using these equations. The Bus occupancy is defined as the ratio of the time required for memory accesses for that data to the time used to send the data. The two equations are defines as follows: Time used for memory accesses: = Number of received bits plus transmitted bits multiplied by the time required to transfer this information to/from memory. = {([6 + (1 + m)] x rc) + (5 + (1 + m)] x tc)} x (1 + 1/ba) x NC x sclk 6 for receive descriptor access 5 for transmit descriptor access (1 + m) for data access where m is the largest integer smaller (n - 1)/4 (n is the number of transmitted data bytes). rc is the number of receive channels. tc is the number of transmit channels. (1 + 1/ba) is the bus arbitration time sclk is the system clock (61 ns for 16.384 MHz) NC is the number of memory clocks per bus operation (0ws = 4, 1WS = 5, etc.). Time used to send the data is the number of transmitted bits per time slot multiplied by the frame time: = ((4 + n) x 8/abtc) x 125 s 4 because shared flags are not used + 2 byte CRC n is the number of octets to transmit abtc = assigned bits to channel e.g. a channel with one time slot of 1 bit would require 8/1 = 8 time slots to transmit a single octet. From the previous example, the variables are assigned the following values: Variable n Value m rc tc (1 + 1/ba) sclk NC abtc 32 bytes 7 32 32 1.1 4 8 User's Manual 217 61 ns 01.2000 PEB 20320 Application Notes Applying these values to the equations yields the following: Time used to access memory = {([6 + (1 + 7)] x 32) + ([5 + (1 + 7)] x 32)} x (1.1) x 4 x 61 ns = {(14 x 32) + (13 x 32)} x 1.1 x 244 ns = {864} x 268.4 ns = 231.9 s. Time used to send data = ((4 + 32) x 8/8) x 125 s. = 36 x 125 s. = 4500 s. Bus occupancy = 231.9 s/4500 s = 5.1% When the packet size is much larger (256 bytes or larger), the bus occupancy decreases to less than 4%. Conversely, sending very small frames (4 bytes), causes bus occupancy to increase to over 11%. This is primarily due to the increased descriptor processing per packet. 5.3.2 Bus Occupancy for Idle Tx Channels The previous discussion shows bus occupancy to be very low, even when a MUNICH32 is processing 32 channels of receive and transmit data. There is another system consideration of bus occupancy that must be examined. When a MUNICH32 channel has no data required for transmit, the channel must be temporarily (or permanently) stopped. There are several methods that may be used to stop the transmission. 1. The first method involves executing a channel command with TH = 1 (reactivation of the channel requires a new channel command with TH = 0). This method places the transmit channel on hold and prevents any further accesses of the memory for this channel. 2. A second method is based on statistical knowledge of the frequency of transmitted frames. If frames are transmitted without shared flags and if the average number of interframe time fill characters can be determined, the MUNICH32 can be programmed to suppress poll sequences. By setting FNUM in the Tx descriptor to a value (n) greater than 0, the MUNICH32 will transmit n + 1 idle characters after the end of the current frame. During this period of interframe time fill, the MUNICH32 will not poll the Tx descriptor. As an example, if it is determined that 5 idle characters typically occur between frames, FNUM can be set to 4. At the end of the current frame, 5 idle characters will be transmitted (625 s. on a DS0 channel) before the next frame is transmitted and no polls of the Tx descriptor will occur during that time. User's Manual 218 01.2000 PEB 20320 Application Notes 3. The final method is to set the HOLD bit in the Tx descriptor. When the HOLD bit in the Tx descriptor is set, the MUNICH32 checks the status of the this bit for each time slot assigned to this channel. In this way, if the bit has been cleared, the MUNICH32 will immediately resume transmission. Although this method is simpler (in concept) for the software design, it causes the MUNICH32 to consume higher than normal bus bandwidth. For this reason, this is the least desirable of the three methods. In the previous example discussed, if all 32 channels were holding on the Tx descriptors, bus occupancy might rise as high as 17%. The reason bus occupancy rises this dramatically is due to the bus access once per time slot rather than once every four time slots (typical). User's Manual 219 01.2000 PEB 20320 Application Hints 6 Application Hints 6.1 Frequency Adaption in an Intel 368 Common Bus System If you use the i386 as host processor with the MUNICH32 in a common bus system you have to adapt the different frequencies of the devices. The MUNICH32 works e.g. with a fixed frequency of 16.384 MHz in CEPT 32 channel PCM highway format. The i386 works with frequencies from 16 up to more than 50 MHz. If you compare the timing diagrams you will see that a few glue logic is necessary to adapt the MUNICH32 to the i386 timing. A possible adaption of the different frequencies is described below. For an example we use an i386 with a frequency of 16.384 MHz. The MUNICH32 is configured in the CEPT 32 channel PCM highway format with a SCLK of 16.384 MHz. The SCLK signal is build by dividing the 32.768 MHz CLK2 signal of the i386. That means that both clocks are synchronous. This is not necessary in general but selected in our example. The bus controller generates e.g. one wait state for the memory access. The falling edge of the ADS signal marks the beginning of a bus cycle which is completed with the sampled READY signal. A general bus controller should not see a difference between the two bus masters, so we have to delay the falling edge of the MUNICH32 ADS signal to that moment as the i386 would generate its ADS to get the READY signal at the same time. In the picture below you can see the relationship and the adaption of both timings as specified in our example. A second picture shows the adaption in an i386 24.576 MHz system. Again the clocks are synchronous. User's Manual 220 01.2000 PEB 20320 Application Hints S1 S2 MUNICH32 SCLK=16.384 MHz SCLK ADS READY T1 T1 T2 T2 T1 i386, 16.384 MHz =>CLK2=2xSCLK CLK2 CLK ADS READY Delay ITD04556 Figure 111 User's Manual 221 01.2000 PEB 20320 Application Hints S1 S2 MUNICH32 SCLK=16.384 MHz SCLK ADS READY T1 T1 T1 T1 T2 T2 T1 i386, 24.576 MHz =>CLK2=3xSCLK CLK2 CLK ADS READY Delay ITD04557 Figure 112 User's Manual 222 01.2000 PEB 20320 Application Hints 6.2 MUNICH32 Memory Space Requirement Implementation independent: - - - - Start Address 4 byte Control & Configuration Section 908 byte Tx Descriptor Size 12 byte Rc Descriptor Size 16 byte Implementation dependent: - Interrupt Queue Size 64 byte < Interrupt Queue Size < 16384 byte - Data Buffer Size Data Buffer Size - Allocation of Tx and Rc descriptors per channel In general the memory space requirement may be calculated the following way: Start Address + Size of Control & Configuration Section + Interrupt Queue Size + number of channels x [number of Tx Descriptors x (Tx Descriptor Size + Data Buffer Size)] + number of channels x [number of Rc Descriptors x (Rc Descriptor Size + Data Buffer Size)] --------------------------------------------- = Total MUNICH32 Memory Space Requirement Example: The MUNICH32 is used in a 31 channel ISDN Primary Access application, that means that 31 full duplex channels are active. The LAPD protocol is implemented. In this case a window size of 7 is specified, that means that 7 Rc Descriptors and in transmit direction 7 Tx Descriptors must be available for each channel. The Data Buffer Size is set to 260 byte according to the LAPD specification. Summary: - - - - 31 channels; Interrupt Queue Size = 1024 byte; 7 Tx and 7 Rc Descriptors; Data Buffer Size = 260 byte; In our example a memory space of 120 kbytes is required. User's Manual 223 01.2000 PEB 20320 Application Hints 6.3 Serial Interface to different PCM Systems The serial interface of the MUNICH32 is very general and comprises standard clock, PCM frame synchronization and data signals, which are independent for both directions. The following description explains typical applications integrating the MUNICH32 into 2.048 Mbps PCM systems, like SIEMENS System Interface for Primary Access and the MITEL ST BUS. In these systems the receive and transmit clocks are identical. The general timing is shown in Figure 113 (see also Chapter 2.1). RCLK=TCLK TSP TDATA Time-Slot 0 RSP RDATA Time-Slot 0 ITD04694 Figure 113 The RSP pulse is shifted by one clock period against the TSP pulse. The main task using this timing for different PCM systems is to adapt the TSP and RSP pulses appropriately, as described below. 6.3.1 MUNICH32 for SIEMENS Primary Access Interface The SIEMENS devices for the Primary Access Interface is the Frame and Line Interface Component (FALC54). This device can directly be connected to the MUNICH32 without any additional glue logic. In combination with the MUNICH32 this application is the most effective way to build a powerful and flexible Primary Access Interface, especially supporting different combined B channel paths over long distances (LAN-WAN Internetworking). The following block diagram illustrates how easy it is to integrate the MUNICH32 into a Primary Access application based on SIEMENS devices. User's Manual 224 01.2000 PEB 20320 Application Hints TCLK TSP TDATA SYPXQ XDI SCLKX FALC54 PEB 2254 MUNICH32 PEB 20320 SCLKR RDO SYPRQ RDATA RSP RCLK CLKX CLK8M FSCQ FSC ITS07370 Figure 114 The adaption of the TSP and RSP pulses is solved by means of shifting the receive data and transmit data in the FALC54 device appropriately. In this case the TSP and RSP synchronization pulses are also identical. The FALC54 device contains special registers to control the bit shift of the serial bit streams at the system interface (see FALC54 Data Sheet). With the following register programming the bit shift selected is T = 509 for the MUNICH32 transmit data and T = - 1 for the receive data respectively. The programming is as follows: XDI: XC1.XTO = 3DH XC0.XCO = 06H RDO: RC1.RTO = 00H RC0.RCO = 05H User's Manual => X = 494 => T = 509 => X = 5 => T = - 1 225 01.2000 PEB 20320 Application Hints The timing in principle is depicted in the following diagram. Without all details of a typical electrical timing it illustrates how the different signals from MUNICH32, and FALC54 are mapped in such a Primary Access system. FSC=TSP=RSP CLKX=RCLK=TCLK TDATA =XDI (T=509) RDATA =RDO (T=-1) ITD08282 = : Invalid area = : Channel 0, Bit 0 (Least Significant Bit) Figure 115 User's Manual 226 01.2000 PEB 20320 Application Hints 6.3.2 MUNICH32 in Systems with MITEL ST BUS A few more effort is necessary to integrate the MUNICH32 into a ST BUS system from MITEL. The basic assumption made here is that the clock master is the ST BUS system. That means all signals derived from the ST BUS need to be adapted to match the MUNICH32 timing requirements. First of all the clock signal C2 must be inverted before it can be used as the MUNICH32 clocks (TCLK = RCLK = C2). The next step is the generation of the TSP and RSP pulses out of the F0 signal, which is the ST BUS frame synchronization signal. The RSP pulse can be derived from the F0 signal by means of a simple D-Flip-Flop clocked with C2, as depicted in the following Figure 116. Due to the necessary phase relationship between the serial data streams and their corresponding TSP, RSP and F0 pulses, the effort to generate the TSP pulse is much higher than for RSP. TCLK TSP TDATA STi MUNICH32 PEB 20320 ST-BUS STo RDATA RSP RCLK C2 F0 Decode '254' Q & Q D RES 8-Bit Counter Q Q D System Clock Adaption ITS04692 Figure 116 User's Manual 227 01.2000 PEB 20320 Application Hints The TSP pulse must be derived from the F0 signal with a phase shift by 255 clock cycles to be at the right position. The corresponding timing is illustrated in the following diagram. C2 F0 TSP *) RSP *) RCLK=TCLK=C2 TDATA =STi RDATA =STo ITD04693 = : Invalid area = : Channel 0, Bit 0 (Least Significant Bit) *) Derived from F0 and synchronized by means of C2 Figure 117 User's Manual 228 01.2000 PEB 20320 Electrical Characteristics 7 Electrical Characteristics Note: All specifications are for V3.4 unless otherwise specified. Version numbers are identified in the Interrupt Information bits VN(3:1): these bits are `0000' for version 1.1 `0001' for version 2.1 `0010' for version 2.2 `0100' for version 3.2 `0110' for version 3.4 7.1 Absolute Maximum Ratings Table 12 Parameter Ambient temperature under bias: PEB PEF Storage temperature Voltage at any pin with respect to ground Symbol TA TA Tstg VS Limit Values Unit min. max. 0 - 40 70 85 C - 65 125 C - 0.4 VDD + 0.4 V Note: Stresses above those listed here may cause permanent damage to the device. Exposure to absolute maximum rating conditions for extended periods may affect device reliability. User's Manual 229 01.2000 PEB 20320 Electrical Characteristics 7.2 DC Characteristics Table 13 TA = 0 to + 70 C; VDD = 5 V 5%, VSS = 0 V Parameter Symbol L-input voltage H-input voltage L-output voltage VIL VIH VQL Limit Values Unit Test Condition min. max. - 0.4 0.8 V - 2.0 VDD + 0.4 V - - 0.45 IQL = 7 mA V (pin TDATA) IQL = 2 mA (all others) H-output voltage VQH VDD - 0.5 - V IQH = - 2 mA (pin HOLD/BR) IQH = - 100 A (all others) VQH ICC 2.4 - < 100 mA power down (no clocks) ICC - <2 mA Input leakage current Output leakage current ILI ILQ - 10 A H-output voltage Power supply current operational V IQH = - 400 A VDD = 5 V inputs at 0 V/VDD, no outputs loads 0 V < VIN < VDD to 0 V 0 V < VOUT < VDD to 0 V Note: The listed characteristics are ensured over the operating range of the integrated circuit. Typical characteristics specify mean values expected over the production spread. If not otherwise specified, typical characteristics apply at TA = 25 C and the given supply voltage. User's Manual 230 01.2000 PEB 20320 Electrical Characteristics 7.3 Capacitances Table 14 TA = 25 C; VDD = 5 V 5%, VSS = 0 V Parameter Symbol Input capacitance Output capacitance I/O-capacitance 7.4 Limit Values CIN COUT CIO Unit Test Condition 10 pF - 15 pF - 20 pF - min. max. 5 8 10 AC Characteristics TA = 0 to + 70 C; VDD = 5 V 5% Inputs are driven to 2.4 V for a logical `1' and to 0.4 V for a logical `0'. Timing measurements are made at 2.0 V for a logical `1' and at 0.8 V for a logical `0'. The AC testing input/output waveforms are shown below. 2.4 2.0 2.0 Device Under Test Test Points 0.8 0.8 C Load = 150 pF 0.45 ITS00621 Figure 118 Input/Output Waveform for AC Tests User's Manual 231 01.2000 PEB 20320 Electrical Characteristics 7.5 Microprocessor Interface Intel Bus Mode S1 S2 S1 SCLK 1 A31-A2 2 BE(3:0), ADS 3 3 4 5 READY 6 7 BERR 8 D31-D0 (write cycle) [DP(3:0)] 9 10 D31-D0 (read cycle) [DP(3:0)] PCHK 11 11 ITD03510 Figure 119 Timing Diagram Intel Bus Mode User's Manual 232 01.2000 PEB 20320 Electrical Characteristics SCLK 12 12 HOLD 13 13 HLDAO 15 14 HLDA 16 Microprocessor Interface 17 High Z High Z PCHK 11 ITD03511 Figure 120 Bus Arbitration Timing Diagram Intel Bus Mode Intel Bus Timing Table 15 No. 1 Parameter Limit Values Unit min. max. Address, valid delay - 20 ns 2 BE, INT, W/R valid delay - 20 ns 3 ADS valid delay - 20 ns 4 READY setup time 10 - ns 5 READY hold time 5 - ns 6 BERR setup time 10 - ns 7 BERR hold time 5 - ns 8 Data valid delay (write) - 35 ns 9 Data setup time (read) 5 - ns 10 Data hold time (read) 8 - ns User's Manual 233 01.2000 PEB 20320 Electrical Characteristics Table 15 No. Parameter Limit Values Unit min. max. 11 Parity check valid delay - 50 ns 12 HOLD valid delay - 20 ns 13 HLDAO valid delay - 20 ns 14 HLDA setup time 10 - ns 15 HLDA hold time 10 - ns 16 Microprocessor Interface (MI) driven after HLDA set 2 SCLK cycles - - 17 MI tristated after bus accesses - 40 ns User's Manual 234 01.2000 PEB 20320 Electrical Characteristics 7.6 Microprocessor Interface Motorola Bus Mode T1 T3 T2 T4 T1 SCLK 18 A31-A2 INT, BE (3:0), R/W 20 26 AS 29 DS 19 28 19 21 21 DSACK BERR 27 22 23 D31-D0 (read cycle) 25 24 D31-D0 (write cycle) ITD03513 Figure 121 Timing Diagram Motorola Bus Mode User's Manual 235 01.2000 PEB 20320 Electrical Characteristics SCLK 30 30 BR 31 32 BG 33 33 BGACK Microprocessor Interface 34 35 BGO 36 SCLK BR BG 36 36 BGO ITD03514 Figure 122 Bus Arbitration Timing Motorola Bus Mode Motorola Bus Timing Table 16 No. Parameter Limit Values Unit min. max. 18 Address, BE, INT, R/W valid delay - 20 ns 19 AS, DS asserted after clock low - 20 ns 20 AS, DS negated after clock low - 20 ns 21 DSACK, BERR setup time to clock low 5 - ns 22 Data read setup time to clock low 5 - ns 23 Data read hold time to clock low 8 - ns User's Manual 236 01.2000 PEB 20320 Electrical Characteristics Table 16 No. Parameter Limit Values Unit min. max. 24 Data write valid delay - 35 ns 25 Data write hold from clock high - 35 ns 26 Address valid to AS high 10 - ns 27 Data valid to DS low 10 - ns 28 DS high to data invalid 5 - ns 29 AS high to address invalid 10 - ns 30 BR valid delay - 25 ns 31 BG setup time to clock high 5 - ns 32 BG hold time after BGACK 10 - ns 33 BGACK valid delay - 25 ns 34 Microprocessor Interface driven after BGACK asserted 1 SCLK cycle - - 35 Clock high to Microprocessor Interface tristated - 40 ns 36 BGO valid delay from clock high - 40 ns 1) Newly specified for V2.1 and V2.2. Not specified in Data Sheet 08.93. User's Manual 237 01.2000 PEB 20320 Electrical Characteristics Serial Interface Timing 37 39 RSP 43 42 RCLK 38 40 41 RDATA 46 44 TSP 50 49 TCLK 45 48 47 TDATA ITD03515 Figure 123 Table 17 No. Parameter Limit Values Unit min. max. 10 - ns 37 Receive strobe guard time 38 Receive strobe setup 5 - ns 39 Receive strobe hold 5 - ns 40 Receive data setup 5 - ns 41 Receive data hold 5 - ns User's Manual 238 01.2000 PEB 20320 Electrical Characteristics Table 17 (cont'd) No. Parameter Limit Values Unit min. max. 42 Receive clock high width 60 - ns 43 Receive clock low width 60 - ns 44 Transmit strobe guard time 20 - ns 45 Transmit strobe setup 5 - ns 46 Transmit strobe hold 5 - ns 47 Transmit data delay - 40 ns 48 Transmit clock to high impedance - 50 ns 49 Transmit clock high width 60 - ns 50 Transmit clock low width 60 - ns Note: 1. The frequency on the serial line must be smaller or equal to 1 th /8 of the frequency on the P bus for 1.536 MHz, 1.544 MHz, 2.048 MHz 1/ th of the frequency on the P bus for 4.096 MHz. 4 2. For complete internal or complete external loop t42 and t49 must be greater or equal to 3 times t51. Clock Input Timing 51 52 53 SCLK ITD03516 Figure 124 Clock Timing User's Manual 239 01.2000 PEB 20320 Electrical Characteristics Table 18 No. Parameter Limit Values Unit min. max 51 Cycle period 50 - ns 52 Clock low time 25 - ns 53 Clock high time 25 - ns Note: If fT is the frequency of the clock TCLK, fR the frequency of the clock RCLK and fS the frequency of the clock SCLK the equations 7.996 x max (fT, fR) fS 16.667 MHZ for CEPT, T1, E1 PCM mode and 3.998 x max (fT, fR) fS 16.667 MHZ for 4.096 MHz PCM mode describe the allowed range of frequencies for fS. System Interface Timing AR 56 RESET 57 first action request AR after reset 55 ITT10668 Figure 125 Table 19 No. Parameter Limit Values min. Unit max. 55 Reset to first action request delay 12 SCLK cycles - - 56 AR# pulse width 2 SCLK cycles 5 SCLK cycles - 57 Reset pulse width 2 SCLK cycles - - After power up a logical `1' at the reset pin of the MUNICH V3.4 sets the device into a reset state where the complete microprocessor bus interface is tristated and the internal reset sequence is started. User's Manual 240 01.2000 PEB 20320 Electrical Characteristics The trailing edge of the reset starts the last part of the internal reset sequence and takes about 12 SCLK cycles. It is not allowed to give an action request (AR) during these first 12 SCLK cycles after the trailing edge of signal RESET. JTAG-Boundary Scan Timing 58 59 60 JTEST0 (TCK) 61 62 JTEST1 (TMS) 63 64 JTEST2 (TDI) 65 JTEST3 (TDO) ITD03512 Figure 126 JTAG-Boundary Scan Timing Table 20 Intel Bus Timing No. Parameter 58 Limit Values JTEST0 (TCK) period Unit min. max. 166 inf - 59 JTEST0 (TCK) high time 80 - - 60 JTEST0 (TCK) low time 80 - - 61 JTEST1 (TMS) setup time 15 - - 62 JTEST1 (TMS) hold time 10 - - 63 JTEST2 (TDI) setup time 15 - - 64 JTEST2 (TDI) hold time 15 - - 65 JTEST3 (TDO) valid delay 30 - - User's Manual 241 01.2000 PEB 20320 Package Outlines 8 Package Outlines GPM05247 P-MQFP-160-1 (Plastic Metric Quad Flat Package) Sorts of Packing Package outlines for tubes, trays etc. are contained in our Data Book "Package Information". Dimensions in mm SMD = Surface Mounted Device User's Manual 242 01.2000 PEB 20320 Appendix 9 Appendix 9.1 Source Code Extract MUNICH32 The MUNICH32 code extract is taken from the low level device driver for the MUNICH32, which is written in `C'. This extract gives you a brief impression how a MUNICH32 device driver could be programmed. The munich control configuration (munichCtrlCfg) is a structure which consists of the following substructures: Action Specification Interrupt Queue Specification Time-Slot Assignment Channel Specification Munich Receive Descriptor Pointer Munich Transmit Descriptor Pointer actionSpec intQueueSpec timeSlot[ ] channelSpec[ ] currRcDescrAddr[ ] currTxDescrAddr[ ] These substructures mainly consist of bit fields. The use of bit fields does not produce a speed optimized but a highly readable code, in our case to demonstrate the programming of the MUNICH32 very clearly. The structures are directly memory mapped to the MUNICH32 structures and listed below. In this short example we select the CEPT-32 PCM highway format and the HDLC mode. All time-slots are assigned to channel number 0. HDLC frames are send via channel0. There are two functions: InitChannel0AndSendFirstFrame() TxHdlcFrame(). The function InitChannel0AndSendFirstFrame() comprises the following initialization tasks: - - - - - - the MUNICH32 is configured for the CEPT32 channel format the interrupt queue is initialized and assigned each time-slot consists of 8 bit and all time-slots are assigned to channel 0 the transmit outputs and the receive inputs are active here nine transmit buffers are assigned to channel0 idle code flags. User's Manual 243 01.2000 PEB 20320 Appendix The second part of the function prepares the device to send the first HDLC frame: - the linked list of frames to be send is registered - in receive direction a linked list of 10 receive descriptors with 32 bytes data each is prepared and installed. - the macro MUNICH32_ACTION_REQUEST() `generates' an activation request pulse to the MUNICH32 - the device reads the initialization data and transmits the first transmit frame The MUNICH32 then polls the hold bit of last transmit descriptor until this bit is cleared. If the hold bit is cleared the device sends the next data until it finds the next hold bit. The function TxHdlcFrame connects the transmit descriptor of the next frame with the last transmit descriptor of the last send frame and clears the hold bit; the next frame is send. User's Manual 244 01.2000 PEB 20320 Appendix 9.2 Source Code ... /*-------------------------------------------------------------------------- MUNICH32 Transmit Descriptor Structure -------------------------------------------------------------------------*/ typedef struct munichTxDescr { unsigned fnum : unsigned csm : unsigned : unsigned v110 : unsigned no : unsigned hi : unsigned hold : unsigned fe : WORD8 _ptr data; struct munichTxDescr _ptr next; } MUNICH_TRANSMIT_DESCRIPTOR; 11; 1; 3; 1; 13; 1; 1; 1; typedef MUNICH_TRANSMIT_DESCRIPTOR _ptr MUNICH_TX_DESCR_PTR /*-------------------------------------------------------------------------- MUNICH32 Receive Descriptor Structure -------------------------------------------------------------------------*/ typedef struct munichRcDescr { unsigned unsigned no unsigned hi unsigned hold unsigned unsigned unsigned status unsigned bno unsigned unsigned c unsigned fe WORD8 _ptr data; struct munichRcDescr _ptr next; } MUNICH_RECEIVE_DESCRIPTOR; User's Manual 245 : : : : : : : : : : : 16; 13; 1; 1; 1; 8; 8; 13; 1; 1; 1; 01.2000 PEB 20320 Appendix typedef MUNICH_RECEIVE_DESCRIPTOR _ptr MUNICH_RC_DESCR_PTR; /*-------------------------------------------------------------------------- MUNICH32 Structures -------------------------------------------------------------------------*/ typedef struct { unsigned channelNumber unsigned rt unsigned unsigned fo unsigned err unsigned sf unsigned ifc unsigned fi unsigned hi unsigned arf unsigned arack unsigned x unsigned sa unsigned sb unsigned e1 unsigned e2 unsigned e3 unsigned e4 unsigned e5 unsigned e6 unsigned e7 unsigned frc unsigned unsigned intFlag } MUNICH32_INTERRUPT_QUEUE; : : : : : : : : : : : : : : : : : : : : : : : : typedef struct { MUNICH32_INTERRUPT_QUEUE _ptr unsigned unsigned } INTERRUPT_QUEUE_SPECIFICATION; addr; n : 8; : 24; 5; 1; 2; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 4; 1; typedef struct { unsigned rcFillMask : 8; unsigned rcChannelNumber : 5; User's Manual 246 01.2000 PEB 20320 Appendix unsigned unsigned unsigned unsigned unsigned unsigned rti : : txFillMask : txChannelNumber : tti : : 1; 2; 8; 5; 1; 2; } TIME_SLOT_ASSIGNMENT; typedef struct { unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned MUNICH_RC_DESCR_PTR MUNICH_TX_DESCR_PTR unsigned unsigned } CHANNEL_SPECIFICATION; iftf mode fa trv crc inv tflagCs tflag ra ro th ta to ti ri nitbs intMask frda; ftda; itbs : : : : : : : : : : : : : : : : : 1; 2; 1; 2; 1; 1; 1; 7; 1; 1; 1; 1; 1; 1; 1; 1; 8; : 6; : 26; typedef struct { WORD32 } CURRENT_RC_DESCR_ADDR; *currentReceiveDescriptorAddrCh; typedef struct { WORD32 } CURRENT_TX_DESCR_ADDR; *currentTransmitDescriptorAddrCh; User's Manual 247 01.2000 PEB 20320 Appendix typedef struct { unsigned unsigned ia unsigned loopi unsigned loop unsigned loc unsigned res unsigned im unsigned channelNumber unsigned unsigned ico unsigned in unsigned mfl unsigned pcm } ACTION_SPECIFICATION; : : : : : : : : : : : : : 2; 1; 1; 1; 1; 1; 1; 5; 1; 1; 1; 13; 3; /*-------------------------------------------------------------------------- MUNICH32 Control Block -------------------------------------------------------------------------*/ typedef struct { ACTION_SPECIFICATION INTERRUPT_QUEUE_SPECIFICATION TIME_SLOT_ASSIGNMENT CHANNEL_SPECIFICATION MUNICH_RC_DESCR_PTR MUNICH_TX_DESCR_PTR } MUNICH32_CTRL_CFG_SECTION; .. .. User's Manual actionSpec; intQueueSpec; timeSlot channelSpec currRcDescrAddr currTxDescrAddr 248 32; 32; 32; 32; 01.2000 PEB 20320 Appendix /*-------------------------------------------------------------------------- Function : InitChannel0AndSendFirstFrame -------------------------------------------------------------------------- Description : Initialization of channel 0. - PCM Highway format CEPT 32-channel - HDLC Mode - All timeslots are assigned to channel 0. - Send the first HDLC frame -------------------------------------------------------------------------*/ static void InitChannel0AndSendFirstFrame ( MUNICH_TX_DESCR_PTR m32TxDescr ) { .. .. /* ------------------------------------------------------------------------*/ txDescr = m32TxDescr /* store transmit descriptor pointer */ /*=== Action Specification ==============================================*/ munichCtrlCfg.actionSpec.in = 1; /* initialization procedure munichCtrlCfg.actionSpec.ico = 0; /* initialize channel only munichCtrlCfg.actionSpec.channelNumber = 0; /* munichCtrlCfg.actionSpec.im = 0; /* interrupt mask munichCtrlCfg.actionSpec.res = 0; /* reset munichCtrlCfg.actionSpec.loopi = 0; /* loops for test purposes munichCtrlCfg.actionSpec.loop = 0; /* loops for test purposes munichCtrlCfg.actionSpec.loc = 0; /* loops for test purposes munichCtrlCfg.actionSpec.ia = 1; /* interrupt attention munichCtrlCfg.actionSpec.pcm = 5; /* PCM, CEPT 32 channel munichCtrlCfg.actionSpec.mfl = 256;/* maximum frame length */ */ */ */ */ */ */ */ */ */ */ /*=== Interrupt Queue Specification =====================================*/ munichCtrlCfg.intQueueSpec.addr munichCtrlCfg.intQueueSpec.n /* interrupt queue address */ = &munichIntQueue [0]; /* interrupt queue size */ = (INT_QUEUE_SIZE_MAX / 16 -1); for ( i = 0; i < INT_QUEUE_SIZE_MAX; i++ ) { munichIntQueue[i].intFlag = CLEAR; } User's Manual 249 /* Reset interrupt queue */ 01.2000 PEB 20320 Appendix /*=== Timeslot Assignment ===============================================*/ for ( i = 0; i < 32; i++) { munichCtrlCfg.timeSlot[i].rcChannelNumber munichCtrlCfg.timeSlot[i].txChannelNumber munichCtrlCfg.timeSlot[i].rcFillMask munichCtrlCfg.timeSlot[i].txFillMask munichCtrlCfg.timeSlot[i].tti munichCtrlCfg.timeSlot[i].rti } = = = = = = /* 0; /* 0; /* 0xFF;/* 0xFF;/* 0; /* 0; /* For all timeslots assigned to channel 0 all bits assigned per channel Tx output active Rc input active */ */ */ */ */ */ */ /*=== Channel Specification =============================================*/ munichCtrlCfg.channelSpec[channel0].intMask munichCtrlCfg.channelSpec[channel0].nitbs munichCtrlCfg.channelSpec[channel0].to munichCtrlCfg.channelSpec[channel0].ta munichCtrlCfg.channelSpec[channel0].ti munichCtrlCfg.channelSpec[channel0].ro munichCtrlCfg.channelSpec[channel0].ra munichCtrlCfg.channelSpec[channel0].ri = = = = = = = = 0; /* interrupts enabled 1; /* new ITBS value 0; /* transmit 1; /* initialization 1; /* 0; /* receive 1; /* initialization 1; /* */ */ */ */ */ */ */ */ munichCtrlCfg.channelSpec[channel0].th munichCtrlCfg.channelSpec[channel0].fa munichCtrlCfg.channelSpec[channel0].tflag munichCtrlCfg.channelSpec[channel0].tflagCs munichCtrlCfg.channelSpec[channel0].inv munichCtrlCfg.channelSpec[channel0].crc munichCtrlCfg.channelSpec[channel0].trv munichCtrlCfg.channelSpec[channel0].mode munichCtrlCfg.channelSpec[channel0].iftf munichCtrlCfg.channelSpec[channel0].itbs = = = = = = = = = = 0; 0; 0; 0; 0; 0; 0; 3; 0; 9; */ */ */ */ */ */ */ */ */ */ munichCtrlCfg.channelSpec[channel0].ftda User's Manual 250 /* /* /* /* /* /* /* /* /* /* no transmit hold no flag adjustment only for TMA CRC select no bit inversion 16-bit CRC transmission rate HDLC Mode idle code flags transmit buffer size = txDescr; /* first transmit */ /* descriptor address */ 01.2000 PEB 20320 Appendix /*=== Transmit Descriptor ===============================================*/ /* the next pointer of the last txDescr points to the zero pointer */ for ( ; txDescr ->next; txDescr { txDescr ->fnum = 3; txDescr ->hold = 0; txDescr ->hi = 0; txDescr ->fe = 0; txDescr ->v110 = 0; } txDescr ->fe = 1; txDescr ->hold = 1; */ */ = txDescr ->next ) /* /* /* /* /* 3 interframe timefill char */ clear hold bit */ clear host initiated interrupt bit */ clear frame end bit */ clear v110 bit */ /* set frame end bit /* set hold bit /*=== Receive Descriptor ================================================*/ rcDescr = AllocReceiveDescriptor(10); munichCtrlCfg.channelSpec[channel0].frda /* Alloc e.g. ten /* receive descriptors /* with 32 data byte each */ */ */ = rcDescr; /* first receive */ /* descriptor address */ /*=== Prepare Receive Descriptor 1 to 9 =================================*/ for ( ; rcDescr ->next; rcDescr = rcDescr ->next ) { rcDescr ->hold = 0; /* not the last descriptor */ rcDescr ->hi = 0; /* no host interrupt */ rcDescr ->no = 32; /* 32 data byte available */ rcDescr ->fe = 0; /* clear frame end bit */ rcDescr ->c = 0; /* clear data section complete bit */ } /*=== Prepare The Last Receive Descriptor, Number 10 ====================*/ rcDescr rcDescr rcDescr rcDescr rcDescr ->hold ->hi ->no ->fe ->c = = = = = 1; 1; 32; 0; 0; channelControl[0].lasttxdescr channelControl[0].lastrcdescr MUNICH32_ACTION_REQUEST (); /* /* /* /* /* last available descriptor no host interrupt 32 data byte available clear frame end bit clear data section complete bit */ */ */ */ */ = txDescr; /* store last transmit pointer */ = rcDescr; /* store last receive pointer */ /* generate MUNICH32 activation request */ } User's Manual 251 01.2000 PEB 20320 Appendix /*-------------------------------------------------------------------------- Function : TxHdlcFrame -------------------------------------------------------------------------- Description : Transmit an HDLC frame via channel 0 -------------------------------------------------------------------------*/ static { .. .. void TxHdlcFrame ( MUNICH_TX_DESCR_PTR m32TxDescr ) /* ------------------------------------------------------------------------*/ m32TxDescr = txDescr; /* store transmit descriptor pointer */ channelControl[0].lasttxdescr ->next = txDescr; /* Add frame to existing */ /* channel0 frame queue */ /*=== Transmit Descriptor ===============================================*/ for ( ; txDescr ->next; txDescr { txDescr ->fnum = 3; txDescr ->hold = 0; txDescr ->hi = 0; txDescr ->fe = 0; txDescr ->v110 = 0; } txDescr ->fe = 1; txDescr ->hold = 1; = txDescr ->next ) /* /* /* /* /* 3 interframe timefill char */ clear hold bit */ clear host initiated interrupt bit */ clear frame end bit */ clear v110 bit */ /* set frame end bit /* set hold bit channelControl[0].lasttxdescr ->hold = 0; channelControl[0].lasttxdescr /* /* /* /* /* */ */ the polling MUNICH32 will then detect the cleared hold bit and send the following frame */ */ */ */ */ = txDescr; /* store last transmit pointer */ } User's Manual 252 01.2000